className vs. object.style.

http://www.quirksmode.org/dom/classchange.html

Hmmm..den går nærmset i dne modsatte retning af hvad Ole påpegede :/

Du kan se testen, og prøve selv.
className er hurtigst.
Men vil meget gerne høre hvad ole har at sige :)
Det kunne jo være det andet var hurtigere i specielle situationer

Bemærk lige hvad testen går ud på, for det er en absolut urealistisk test, når det gælder om at ændre ved hjælp af object.style !-)

-- hvis man skal ændre udseende eller placering for nogle objekter på en live side, vil det _aldrig_ være at ændre en property på 1700 tabelceller, men på et enkelt eller en afgrænset samling af elementer ...

-- det kunne f.eks. være på en tabelrække den ene vej og på en anden række tilbage til original-tilstanden, og så kan man jo prøve at udføre den test en masse gange !o]

<ole>

Der er ikke så meget at uddybe - specielt ikke efter, roenving har gjort det  :)

Ja, quirksmode.org har lavet et eksempel, der synes at bevise det modsatte af, hvad jeg (og Microsoft) 'påstår'. Man kan næsten altid lave én eller anden opstilling, der bekræfter ens påstande - bare se, den måde 'undersøgelser' (mis)bruges politisk.

Som Bohr sagde:
  "Det, vi oplever er ikke naturen - men naturen udsat for vores måde at spørge på"  ;o)

Som roenving dog anfører, så opfører dokumentet sig helt anderledes ud, når man tester på et realistisk scenarium. Derfor ser tingene ikke anderledes ud i specielle situationer ... tværtimod er det i en helt speciel, yderst sjælden situation, tingene ser ud, som quirksmode.org viser  ;o)

/mvh
</bole>

Jeg havde ikke set den ting fra quirksmode.org før jeg spurgte, og jeg syntes heller ikke rigtigt den giver nogen indsigt i forskellen på de to metoder andet end hastigheden ved et specifikt scenarie. Jeg spørger, ganske uskyldigt, fordi det lyder som om du kan levere lidt 'insight' i hvad forskellen på de to måder er, da det på din kommentar om DOM træ...(hvad det så end er)...lyder som om der er mulighed for at udvide min user agent vs. html forståelse. Håber du stadig har mod på en mere dybdegående forklaring.

Og tag du bare din tid, jeg har ikke travlt ;-)

Mvh. Johan

Et dokuments DOM beskriver sammenhængene mellem sidens elementer:
"head-elementet er 'barn' af document-elementet - og 'søster' til body-elementet" ... osv.
Ethvert elements 'stamtræ' er således en delmængde af dokumentets DOM.

Når CSS (en sjælden gang imellem) bliver brugt korrekt (sådan, som teknologien er tænkt), er et HTML-dokuments styling en yderst kompliceret fætter  :)
Da hele tanken bag CSS er 'nedarvning' (bl.a. via klasser og DOM), bliver det hurtigt meget indviklet, hvis du skifter en klasse et eller andet sted i dokumentet, ændrer du således på al efterfølgende arv.

Hvis din tip-tip-tip-tip-oldefar pludselig viser sig at høre til en helt anden familie, kommer mange forhold i din familie til at se helt anderledes ud. Din genetik vil være en helt anden, end du troede - og skal vi gå tilbage og se på, hvad der har været arvet ned gennem familien af værdier, er de egentlige/teoretiske ejerforhold helt anderledes, end du troede (og sådan som de med tiden fejlagtigt er behandlet af div. domstole).
Hvis der altså _virkelig_ skal være styr på tingene, er du nødt til at skrive hele din slægtshistorie om, når du opdager, der er sket en forbytning i et led langt tilbage.

Dét er, hvad der - i overført betydning - sker, når du skifter en CSS-klasse.

Jeg ved ikke, om det gør tingene mere tydelige. Det kan være lidt vanskeligt at forklare for folk, der måske ikke er helt stærk i CSS og DOM, hvorfor jeg føler mig tvunget til at forklare fænomenet med analogier.
Den slags forklaringer bliver sjældent pinligt nøjagtige i teknisk henseende, men plejer at kunne give en rimelig fornemmelse for sammenhængene  :)

Jeg kan måske tydeliggøre det lidt:

Vi har et div-element med klassen 'gnu'. Browseren må gå udfra, koderen gør brug af CSS' styrker og muligheder - og derfor må den gå udfra, der er elementer i div'et, der arver reglerne fra div'ets grundlæggende CSS-regler - samt arve fra klassen 'gnu' ... f.eks:

.gnu .hest a {
  /* CSS-regler */
}

Ændrer du div'ets klasse til 'strangeAnimal', ændrer du således en masse komplicerede 'familieforhold' i dokumentet.

'Nøjes' du derimod med at ændre nogle style-properties på div-elementet, ændrer du ikke ved arveforhold. Alle de elementer, der skal arve efter div'et (og dets klasse), gør det stadig - uden ekstra beregninger  ;o)

Hmm langsomt tændes der et lys men forløbig tror jeg kun det er en 20W pære :-)

Kan man udtrykke princippet således. I den klasse jeg definere for et div, kan der være hentydninger til mange forskellige elementer, i div'et, som 'arver' egenskaberne. Derfor vil det oftest være bedre at ændre det enkelte elements style-properties i stedet for at ændrer alle elementernes oldefar, da det vil påvirke elementer som ikke får ændret deres style-properties men blot får en identisk oldefar med et andet navn ?

Så i 'simple' tilfælde, hvor klassen kun påvirker et element, er der ikke den store forskel på hvilken metode man bruger...eller ?

Mvh. Johan

Ja, sådan kan du godt udtrykke det  :)

Det er dog aldrig smart at bygge sin kodestil på den slags betragtninger. I stedet bør man basere sin kode på det værste scenarium ... så undgår man at begå fejl, når det virkelig betyder noget - og det gør det meget ofte, når vi tale style-ændringer ved klasseskift.
Den slags overvejelser bør altid undgåes, for man tager ofte fejl, når man på 20. time sidder og koder noget, der skal være færdigt 'imorgen tidlig'.

Det svarer lidt til at sikre sig, at de HTML-attributter, der _skal_ escapes med gåseøjne, bliver det. Det gør man ved _altid_ at escape _alle_ HTML-attributter - uanset, om standarden siger, det ikke er strengt nødvendigt i det enkelte tilfælde  :)

I en situation, hvor klasseskift er hurtigere, er der tale om få msek.
I en situation, hvor det modsatte er tilfældet, handler forskellen i værste fald om hele sekunder.

- det burde gøre valget ret enkelt at træffe  ;o)

Se det er jo et princip der er værd at huske :-)

Tak for forklaringen.

Jeg lukker selv her - det håber jeg du er ok med.

Mvh. Johan