<td onmouseover="this.style.backgroundColor='black';this.style.color='white'" onmouseout="this.style.backgroundColor='white';this.style.color='black'"> min tekst<br> kommer her </td>
FYI: Faktisk så har IE7 implementeret :hover funktionen på andre elementer end et a tag.
Så der faktisk ikke grund til at bruge JavaScript, med mindre det også skal virke i ældre versioner af IE, og hvis det er tilfældet, ville jeg anvendet csshover.htc som jokkejensen foreslår.
Nu er kategorien jo CSS, så det var mit udgangspunkt. Og om det ønskede er layout eller funktionalitet er vel et smp om hvordan man ser det. Efter min mening er der ikke meget funktionalitet i en hover effekt. Og efter min mening er det layout. Og mit indspark var bare tænkt som en FYI
Der har været megen debat internt i W3C om emnet. Der er næppe tvivl om, at layout er og alle dage har været en statisk ting - og at hover er en funktionalitet - men af historiske årsager har man (desværre) valgt at lade hover forblive i CSS
psuedo klasserne er bare til leg. De har i hvert fald intet formål når det kan løses med JS, altså med tunnelbrillerne på, en funktion.
En ting ved jeg, JS er ikke tænkt som noget inline crap man kaster på sit markup, det skal ligge externt i en JS fil. Og her tænker jeg, hvorfor skrive en helvedes masse JS for at ramme tags'ene og give dem deres event's frem for at løse det gennem CSS.
Så skal han have en JS løsning må det helt korrekte være at tildele onmouseover og onmouseout dynamisk gennem en JS fil, hvor man giver dem nye klasse navne.
jokkejensen >> quirksmode er herostratisk berømt for at lave én enkelt test - for derefter at konkludere på dén. Ja, den test siger en hel masse ... om forfatteren - og de, der ukritisk mener at, 'den siger alt'.
Den slags 'test' burde ingen tage alvorligt. Det er jo ren Erasmus Montanus: "En sten kan ikke flyve. Mor Karen kan ikke flyve ... ergo: Mor Karen er en sten!" ;D Eller, hvad med den pige jeg engang kendte? Hun gik til lægen og fik p-piller. Samme dag faldt hun og brækkede benet. Ville du derudaf konkludere, at p-piller udgør en reel fare med hensyn til benbrud?
Roenving og jeg har før klasket den pågældende 'test' langt opad væggen med alternative, mere realistiske test - hvor det på en stor side tog op til flere sekunder at rendere siden ved klasseskift.
I mine øjne adskiller du dig ikke fra fundamentalistsik religiøse, når du gang på gang ukritisk kaster dig på maven for forfatteren bag quirksmode - uagtet, at hans påstande tilbagevises den ene gang efter den anden.
Det undrer mig dybt at se mennesker på den måde lader sig forføre af en eller anden tilfældig skribent på WWW. Det er mig en gåde, at man i 2008 ikke har lært, at enhver påstand (specielt, når de bygger på et _så_ spinkelt grundlag) er komplet værdiløs, til den er testet i forskellige sammenhænge og under forskellige forhold. Hvordan kan man dog være så uvidende?
Vi har før diskuteret quirksmodes latterlige påstande om innerHTML's performance. De bygger ligeledes på én enkelt test, hvor han - komplet urealistisk - nøjes med at indsætte ét enkelt tegn i et par tusinde elementer. Absolut uvidenskabelig og helt uden værdi. At andre så laver mere realistiske og omfattende test ( f.eks: http://www.dengodekode.dk/artikler/DOM/no_innerhtml.php ), kan ikke rykke din én gang fastlåste tro!
"Jeg ved godt hvad der er hurtigst."
Nej, du ved ikke en dyt - men du tror en masse ;o)
- og lad mig lige opsummere: Der er i W3C rimelig koncensus om, at hover ikke hører hjemme i CSS, men at denne funktionalitet burde klares med script. Diskussionen har primært gået på, om man skulle fjerne den eller ej. Af historiske årsager har man valgt at lade den blive. Det er med andre ord ikke kun mig, du er uenig med. Din opfattelse er i direkte modstrid med størstedelen af W3C's =)
Lad mig se dig og roenvings test. (kom lige med noget denne gang)
Du propper os jo også bare med din viden (hvad du tror), ingen dokumentation og tør ikke vise nogen reference til en løsning du har lavet?. Altså bare endnu en WWW gut, der ikke bare forsøger af forføre, men direkte diktere hvordan ting skal være..
I givet fald så er du da noget af det mest narcisitiske, bedrevidende individ jeg er stødt på. At svine en anden nok noget mere anerkendt forfatter til, og der efter refere til en artikel med faktum skrevet af dig selv...
Ligegyldigt om du har skrevet den eller ej, så er den ikke særlig objecttiv, når der indledes med "Læseren vil ikke være i tvivl om, jeg selv er modstander af innerHTML".
Hvad mon konklusionen på sådan en artikel vil ende ?
Lol den test der er derinde, laver 5 elementer(p, strong, div, span, em), og resten er en helvedes masse tekst.. Prøv at fjerne dde 2.36MB tekst og se hvad testen siger.
Latterligt scenarie de har opsat inde på dengodekode, det kan umuligt være din test.
og lad venligst være med at lære mig om javascript w13, jeg ved godt hvad javascript er. Samtidigt glemmer jeg ikke din kommentar med at fejlhåndtering klares af DOM.. totalt usammenhængende.
"Det undrer mig dybt at se mennesker på den måde lader sig forføre af en eller anden tilfældig skribent på WWW."
Den skal du måske tage lidt til dig også, og lade være med at tale olebole efter munden.
jokkejensen >> Om det er min test - og dermed f.eks. GMail - som er latterlig eller det evt. skulle være dig, der er det, vil jeg af hensyn til Ekspertens regler om god tone afholde mig fra at udtale mig om. Ikke desto mindre passer min test udmærket med, hvad der loades af data i applikationer som f.eks. GMail og tusindvis af corporate webapplikationer rundt om på WWW.
De utallige gange du og et par andre brugere har diskuteret denne slags emner med mig, har det for Jer udelukkende drejet sig om min person - aldrig om koden. Oven i købet i sådan en grad, at en af de andre brugere (montago) i en tidligere tråd blankt erkendte, at det var min person, som var problemet ... intet andet! Talking about 'narcissisme' ...!!!
Jeg sviner ikke nogen somhelst forfatter til - det skal man være mere end primitiv for at få ud af mine skriverier. Jeg forholder mig kritisk til forfatterens helt fejlagtige påstande. Undskyld, men sådan gør begavede mennesker ofte i stedet for at kaste sig ukritisk på maven for udtalelser, man end ikke har gidet at investere tid i at tjekke rigtigheden af. Men jeg har jo før måtte erkende, at du ikke evner at kende forskel på at diskutere en person - og så på at diskutere hans arbejde.
Hvad påstandende om skift af CSS-klasse angår, så behøver man end ikke tjekke noget somhelst. Hvis man har forstået de mest grundlæggende principper bag CSS, står det lysende klart, at klasseskift naturligvis performer væsentligt dårligere i rigtig mange tilfælde ... det burde faktisk slet ikke være nødvendigt at teste noget. Det er vel derfor, MS i mange år har advaret mod klassskifts dårlige performance - og i stedet råder til skift af de enkelte style properties. Men de er vel også bare nogle 'narcissistiske, bedrevidende individer', som kun er ude på at 'svine en anerkendt forfatter' til. Tag dig dog sammen!
Nu har du tydeligvis ikke erfaring med at skrive artikler, så lad mig fortælle dig lidt om processen: Jeg ved, det kommer som et chok for dig, men normalt ønsker en forfatter at skrive om noget, han ved noget om og har undersøgt. Derfor ved han også ret præcist, hvordan artiklens begyndelse og slutning skal være. Vidste han ikke det, ville det være en umulighed at fremstille problemerne på en bare nogenlunde pædagogisk måde. Hvis han ikke vidste, hvad han skulle skrive, ville han formodentlig aldrig komme igang - for han ville så naturligvis ikke kende til behovet for den pågældende artikel. Det må vist siges at være 'højtlæsning for pygmæer' ;o)
Det har intet med manglende objektivitet at gøre ... tværtimod! Det har noget med overblik og troværdighed at gøre.
At du finder det mere troværdigt og objektivt, at en forfatter skulle kaste sig ud i at skrive noget, han ikke ved noget om, giver indtryk af en person, der ikke tænker sig ret meget om, før han farer i tastaturet!
Naturligvis kendte jeg konklussionen, inden jeg skrev artiklen. Jeg havde selvfølgelig foretaget alle test i forvejen ... ellers havde jeg for pokker da ikke vidst, der var noget at skrive om! Hvad i alverden havde du dog forestillet dig?
Dine seneste kommentarer viser, hvor desparat du er. Hvad i w13's kode, der er 'forkert opbygget', ved enhver med forstand på webkode, du ikke kan gøre rede for. Der er _intet_ forkert i koden. At du på den mest infantile vis er nødt til at understrege dine vrøvlerier med bandeord, understreger blot din ynkelige desparation!
JavaScript - eller rettere LiveScript - blev udviklet af Netscape. Sproget blev lanceret i Netscape 2.0 med det nye navn JavaScript - og til at manipulere HTML-elementer med. Hvis du kender en anden historie, er jeg meget interesseret i at høre den - og det er der vist tusindvis af andre, der også er =)
Olebole >> find noget objecttivt data på dine kommentater ellers kan jeg ikke bruge dem til noget. Du laver jo ikke andet end at tale uden om emnet.
"er udelukkende drejet sig om min person - aldrig om koden" -> netop nu drejer det her sig om koden, så se lige væk fra dig selv et øjeblik.
Vi kan godt bringe den ned på et mere personligt plan.
Men se lige hvad jeg har fundet fra en der er super go til at skrive artikler:
Derfor foreslog W3C (som bl.a. består af de væsentlige browser leverandører) at opdele WWW kode i følgende bestanddele: 1. data 2. markup (elementer til adskillelse af data med henblik på visning) 3. visuel strukturering (styling af markup) 4. funktion (scripting på data og elmenter/styling)
*) Når w13 giver mig ret, taler han mig efter munden. *) Når jeg imødegår en forfatters påstande, er jeg narcissistisk og bedrevidende i mit forsøg på at svine ham til.
You're damned if you do ... n' you're damned if you don't! :D
Der findes en service på Internettet, (et sted hvor man kan se hjemmesider) der hedder google.com, her kan man søge efter sider på Internettet. Fordi der er så mange sider gør det uoverskueligt at skulle kigge alle sider på Internetttet igennem.
Mon ikke man skulle teste om tingene virker i de browsere, det skal virke i og om hastigheden på den ene eller den anden måde virker hurtigst, og så vælge det mest effektive til det valgte scenarie ? Lidt ligesom når vi anbefaler brug af table istedet for div i tilfælde, hvor det er det mest gunstige element til opbygningen ...
Selv har jeg aldrig været meget for brug af f.eks. eval(), men ved en lille test herinde*, viste det sig mest effektivt (i det scenarie efter min holdning). Derfor kan det andet godt være bedre uden eval i et modsat scenarie ... * ( http://www.eksperten.dk/spm/832817#rid7125770 )
Derfor vil jeg da gerne stå ved at selvom innerhtml eller klasse skifte ikke lige er min kop te heller (som eval()), så skal jeg da lade det være usagt at det ikke performer bedre i visse tilfælde.
M.h.t. at putte scriptkoder i html dokumentet undgår jeg helst selv dette på min egen side, men ved kodning på eksperten gør jeg det som w13 til tider, da det til dels ikke altid er synligt hvordan man kan hæfte det til elementer via handlers og da det måske i nogle tilfælde virker mere uhåndterbart end med inline event handlers for nogle brugere.
Mon ikke man hellere skulle klandre browsere for at inkludere kodningsmåder istedet for at klandre brug af disse kodningsmåder ?
Hej... Jeg tror aldrig vi opnår enighed her... Hvem som har ret er jo et spm om religion... Tror ikke vi når meget tættere på hinanden, sådan lige med det første. Faktum er at "meyer" er glad for for løsningen. Jeg har før deltaget i diskutioner på dette forum, og det er sjældent der er komme noget godt ud af det. Og bryder mig faktisk ikke om de verbale angreb. Jeg er sikker på at hjælpen her på e, er givet du fra de beste intentioner. Og løsningen vælges af spørgeren, ud fra hvad der passer ham/hende bedst. Vi kan være enige eller uenige, men som vi ser, findes der mange veje til målet. Jeg må bare selv konstatere, at selv om jeg godt vil holde mig til teorierne er det bare ikke altid praktisk muligt, af forskellige grunde som man ikke selv er herre over. Og vælger derfor den nemme workaround. Over and out.
mclemens >> pas på, hvad du roder dig ud i. Den vej har jeg også været nede af, men det ændrer ikke på holdningerne fra 'visse' brugere :o|
Jeg er derudover helt enig i, at man bør teste for performance. Det er faktisk lige netop dét, jeg slår på tromme for: Tro ikke på, hvad du læser på WWW ... test selv! Det gælder da naturligvis også, hvad jeg skriver i mine artikler: test det selv!
Hele essensen i det, jeg skriver, er jo netop, at quirksmode's forfatter gør sig skyldig i dybt uvidenskabelig folkeforførelse. Han tester ét - meget lidt sandsynligt - scenarium og konkluderer herpå, hvordan virkeligheden ser ud i ethvert andet tilfælde. Den fremgangsmåde er jo netop af den slags, som ender op i at stemple P-piller som farlige med hensyn til brækkede ben (jvnf. kommentaren 23/06-2008 16:07:40) ;o)
mclemens >> Hvad dit eval eksempel angår, så har jeg endnu ikke testet det. Hvad der er interessant i lige netop dét eksempel er dog ikke så meget performance i betydningen 'afviklings hastighed'. Når det gælder event handlers på HTML elementer (JavaScript og DOM), er det memory leaks i IE, der er det helt store issue. De er nemlig ekstremt lette at konstruere - bl.a. ved cirkulære referencer og closures :o|
Man kunne såmænd også argumentere for, at hele innerHTML-kontra-DOM debatten i forbindelse med Ajax er temmelig uinteressant, når det i forvejen tager fra fire-fem gange til tusindvis af gange længere tid at udskrive HTML på serveren, end det gør at udskrive JSON (alt efter metoderne). Da performance er et langt større problem på en travl og altid overbebyrdet server, end på brugerens maskine, der strutter af ubrugt RAM og CPU kraft, er det indlysende at bruge JSON eller XML. Da JSON og XML samtidig arbejder fabelagtig godt sammen med DOM, er valget uhyre let at træffe =)
Tjoh tildels fremgår det af artiklen hos quirkmode, at testen viser at det er hurtigere med innerHTML - jeg kan så give dig ret i at der ikke samtidig er inkluderet en test, der viser at det er langsommere ved større indhold, der indsættes (evt. flere gange for at få en hastighedsmåling).
Din konklusion er jo også rigtig "innerHTML ikke nødvendigvis er hurtigere end DOM - nogen gange tværtimod" - den samme sætning kan afhængig af scenario vendes om og være ligeså korrekt (som også vist af dit første eksempel).
Jeg tror aldrig tilfælde to ville blive relevant for mig - i sådan et tilfælde ville jeg næsten føle at en side opdatering (sideskifte) ville være at foretrække.
Som Jokke føler jeg nok også at du lægger vægt på at innerHTML'en ikke duer, selvom dit eget første eksempel er bevis herfor - det samme kan måske være gældende for andre der vælger innerHTML'en. Jeg føler med andre ord at konklusionen er at "innerHTML er langsommere eller hurtigere end DOM - afhængig af hvilket indhold der skal indsættes". At jeg så nok selv ville foretrække* DOM er så en anden ting ... (*forudsat selvfølgelig at innerHTML ikke viste sig at være sekunder hurtigere ...)
Så må jeg forklare mig dårligt, eller også misforstår du noget =)
Performance tvisten er i virkeligheden den mindst interessante - men sært nok den eneste, folk diskuterer.
Jeg forsøger jo netop at vise med hele to eksempler, at innerHTML er en rigtig skidt ting, fordi den overskriver det fragment, den bruges på. Herved slettes programmatisk satte event handlers og andre referencer til og fra fragmentet - ligesom formfelter mister deres brugerændrede indhold, samt radios og checkbox'e deres checked-værdier.
Samtidig har innerHTML aldig været valid i nogen standard og bliver det heller aldrig. Den strider lodret mod hele webkodens væsen ... hele idéen med, hvordan HTML dokumentet og dets elementer i følge W3C bør opfattes og bearbejdes.
Hvorfor overhovedet bekymre sig om valid kode, hvis man alligevel bruger innerHTML? Hvormange procent invaliditet skal jeg acceptere? Hvilke former for invaliditet skal jeg acceptere og i hvilket omfang? Kan invalide properties og metoder ligefrem være værd at hylde i varme vendinger? Ikke i min verden!
Artiklen har for såvidt to formål:
1) At vise, at innerHTML af mange grunde er en skidt ting at bruge 2) At vise, at man ikke skal tro på, hvad der står på nettet - eller nogen somhelst andre steder - men teste og undersøge selv
"Tjoh tildels fremgår det af artiklen hos quirkmode, at testen viser at det er hurtigere med innerHTML" >> Tildels ...?!??!!! Hvad med:
Discussion The most obvious conclusion of these tests is that innerHTML is faster than "real" W3C DOM methods in all browsers. The W3C DOM table methods are slow to very slow, especially in Explorer.
- og resten af, hvad han skriver, baserer sig på ét eksempel, hvor han indsætter ét tegn i hvert element! Han konkluderer helt klart og tydeligt udfra et specialtilfælde, som jeg end ikke kan komme på nogen praktisk brug af. Ubrugeligt og ligegyldigt vrøvleri!
Jeg kan da godt læsse en VW 1300 med otte småfede mennesker og lade den hoste sig op gennem passene i Østrig. Udfra sådan en tur kan der ikke drages den 'indlysende konklussion', at en VW 1300 generelt kører fire kilometer på en liter benzin. Gjorde jeg det, ville jeg fylde folk med vås!
Med kun mig bag rattet, ned ad bakke og i medvind, ser tingene helt anderledes ud. Hvis jeg vil tale om VW 1300's generelle benzinøkonomi og tages alvorlig, må jeg lave nogle mere alsidige undersøgelser ;o)
Bemærk: Han taler om en 'indlysende konklussion'! Indlysende ...?!??!!!
Ja, såfremt sletningen af de påsatte handlers m.v. har betydning skal man have det med i ens overvejelser når man vælger metode.
(Og at innerHTML ikke er fra w3c bør også indgå som du nævner - men den er selvfølgelig stadig valid i nogle browsere selvom den ikke er en del af standarderne).
W3C afgør hvilke DOM properties, der er valide. At visse invalide properties virker i nogle browsere, gør absolut ikke disse properties valide på nogen somhelst måde. Al mulig skodkode virker i forskellige browsere. Det gør på ingen måde skodkode valid ;o)
Hans konklusion er ikke forkert for testen han har foretaget, men at han ikke teste yderligere er så en fejl. Derfor vises det også kun tildels at det er hurtigere (da den anden test mangler).
8 småfede på tur i Østrig - hmm, mon ikke der ville mangle plads til fastfood når man kører forbi drivein hos Burger King ... :-/
Nej, hans konklusion er rablende forkert! Han skriver jo netop, at det er indlysende, at innerHTML er hurtigere end DOM i alle browsere - og at det bevises af hans test.
Han skriver _netop_ ikke, at det _kun_ gælder i nogle specielle tilfælde - f.eks. hans test. Og bemærk venligts, at han end ikke nævner 'den anden test' ... han konkluderer helt generelt:
"Den mest indlysende konklusion af disse test er, at innerHTML er hurtigere end 'rigtig' W3C DOM i alle browsere".
Nej, det er noget vrøvl! Der skulle i det aller mindste stå:
"Den mest indlysende konklusion af disse test er, at innerHTML i denne ene situation er hurtigere end 'rigtig' W3C DOM i alle browsere".
Der er en verden til forskel! Og så ville det jo også have klædt ham at oplyse, at scenariet udelukkende er af akademisk interesse.
Hvornår er det lige, at én enkel test er blevet taget til indtægt for noget somhelst. Én test er ingen test! Det står i begyndelsen af linje to i forordet til Håndbog i videnskabelig metode ;o)
- og hele problemet er jo, at så ekstremt mange mennesker har læst hans artikel og - med ham - konkluderer, at innerHTML generelt og altid er hurtigere DOM i alle browsere.
Gid alle andre dog læste det, som du gør - omend jeg er dybt uenig i din udlægning =)
24/06-2008 19:13:08 - > Jamen vi er skam ikke uenige på det punkt Ole, jeg synes bare at han tildels har ret i, at det er hurtigere i det tilfælde han har stablet på benene. Vi er også enige i at det ikke er det mest reele billede af brugen på innerHTML og at resultatet derfor kun tildels er sandt.
... Min udlægning er måske for blød og jeg burde nok forholde mig til at hans manglende analyse af problemets omfang og effektivitet af metoderne i et mere naturligt miljø viser noget om hans mangel på subjektivitet og det er jo også sandt - enten er det tilfældet eller også er han blot uvidende om denne fejl.
Hvis det er nogen trøst, så læste jeg ikke artiklen før jeg klikkede på dit link :)
Der er vist ingen udover jokkejensen, der er imod event handlers i markup'en. Opdelingen gælder - ganske som jokkejensen så lyrisk citterede i et af sine mere desparate indlæg (24/06-2008 16:43:40) - selve funktionaliteten ... ikke de håndtag, der udløser den.
Event handlers i markup'en er da også en integreret del af XML Events, som kommer til at erstatte den nuværende event model, når vi for alvor overgår til XHTML. Her får vi sågar et decideret listener-element - så heller ikke hos W3C ser det ud til, at jokkes udlægning af kodens opdeling deles =)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Slettet bruger
Ny bruger
Nybegynder
Opret
Preview
