---

Jeg synes det er pinligt at spørge om, men jeg har aldrig rigtig
lært det grundliggende i CSS og derfor føler jeg mig lidt nød til
at spørge, bl.a for at opnå bedre forståelse.

Hvad er forskellen på div#ID og #ID?

Hver side kan kun have 1 element pr. ID ifølge standarderne.
Men jeg kan ikke rigtig sætte en finger på om der er forskellen
på brugen af div#ID og #ID.
Nogle af de templates jeg har haft fingre i har bestået
hovedsageligt af div#ID's mens andre ikke har indeholdt én
eneste...

//Jahirah

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Jahirah wrote:
> Jeg synes det er pinligt at spørge om, men jeg har aldrig rigtig
> lært det grundliggende i CSS og derfor føler jeg mig lidt nød til
> at spørge, bl.a for at opnå bedre forståelse.
>
> Hvad er forskellen på div#ID og #ID?
>
> Hver side kan kun have 1 element pr. ID ifølge standarderne.
> Men jeg kan ikke rigtig sætte en finger på om der er forskellen
> på brugen af div#ID og #ID.
> Nogle af de templates jeg har haft fingre i har bestået
> hovedsageligt af div#ID's mens andre ikke har indeholdt én
> eneste...

Det kan være af flere årsager.

1. (Og nok den mest brugbare) - er for at fortælle evt. andre udviklere
- eller en selv, når man kommer tilbage senere til CSS filen - at ID'et
er tilkoblet en DIV. Det kan reelt set være at betragte som en form for
"kommentar". Det kan være praktisk, da f.eks. et SPAN element og et DIV
element har forskellige egenskaber (pr. standard).

2. (Og nok den mere tvivlsomme) - er at der bruges samme ID til flere
ting. F.eks. hvis man har et side, hvor indholdet ligger i en tabel - og
en anden hvor indholdet ligger i en div, kan man bruge henholdvis div#ID
eller table#ID til at style elementerne med.

Derudover kan der selvfølgelig også være tale om at nogle brugere,
simpelthen ikke ved et ID er unikt - og derfor bruger den som et
alternativ til class ;)

Men ovenstående 2 er reelt gæt. Der er ingen praktisk forskel på den ene
eller anden.

Mvh
Johan

---

Johan Holst Nielsen har bragt dette til os:
> Jahirah wrote:
>> Jeg synes det er pinligt at spørge om, men jeg har aldrig rigtig
>> lært det grundliggende i CSS og derfor føler jeg mig lidt nød til
>> at spørge, bl.a for at opnå bedre forståelse.
>>
>> Hvad er forskellen på div#ID og #ID?
>>
>> Hver side kan kun have 1 element pr. ID ifølge standarderne.
>> Men jeg kan ikke rigtig sætte en finger på om der er forskellen
>> på brugen af div#ID og #ID.
>> Nogle af de templates jeg har haft fingre i har bestået
>> hovedsageligt af div#ID's mens andre ikke har indeholdt én
>> eneste...
>
> Det kan være af flere årsager.
>
> 1. (Og nok den mest brugbare) - er for at fortælle evt. andre udviklere
> - eller en selv, når man kommer tilbage senere til CSS filen - at ID'et
> er tilkoblet en DIV. Det kan reelt set være at betragte som en form for
> "kommentar". Det kan være praktisk, da f.eks. et SPAN element og et DIV
> element har forskellige egenskaber (pr. standard).
>
> 2. (Og nok den mere tvivlsomme) - er at der bruges samme ID til flere
> ting. F.eks. hvis man har et side, hvor indholdet ligger i en tabel - og
> en anden hvor indholdet ligger i en div, kan man bruge henholdvis div#ID
> eller table#ID til at style elementerne med.
>
> Derudover kan der selvfølgelig også være tale om at nogle brugere,
> simpelthen ikke ved et ID er unikt - og derfor bruger den som et
> alternativ til class ;)
>
> Men ovenstående 2 er reelt gæt. Der er ingen praktisk forskel på den ene
> eller anden.
>
> Mvh
> Johan

#ID sætter værdier for et hvilket som helst element, med id="ID".
div#ID sætter værdier for en div med id="ID"

Som John er inde på, skal id være unikt i et dokument, så den praktiske
forskel er minimal. Mest et spørgsmål om hvordan man læser sin CSS..

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Johan Holst Nielsen skrev:

> 2. (Og nok den mere tvivlsomme) - er at der bruges samme ID til flere
> ting. F.eks. hvis man har et side, hvor indholdet ligger i en tabel - og
> en anden hvor indholdet ligger i en div, kan man bruge henholdvis div#ID
> eller table#ID til at style elementerne med.

Der kan også være en tredje, eftersom det har været diskuteret en teori
om, at der er en performance-optimering i at være så specifik som muligt.

Idéen skulle så være, at i og med, man specificerer hvor den ID (eller
class for den sags skyld) hører til, skal browseren arbejde mindre for
at finde den i DOMen (tror det er sådan noget lignende).

Hvis man forudsætter, at der _er_ noget performance at hente, kan man
kommentere som så:

1. Jo mere specifik man er, des mere vil ens CSS fylde. Derfor er det
vigtigt, at det kan cashes. Der må så også være et skæringspunkt for,
hvor det kan betale sig og hvor ikke.

2. Man riskerer at begrænse sig for meget, hvis man er alt for specifik.

Jeg kan ikke huske, hvor jeg har læst det med performance, desværre, så
jeg kan ikke sige, om det passer, men det er jo så alle tiders chance
for andre til at skyde teorien ned, hvis det er.

Men at performance generelt har en del at sige, det vil jeg nu godt være
med til. Yahoo har lavet flere forsøg, som beviser dette. Bare ét
sekunds længere "svartid", og brugerne kan blive så utålmodige, de
finder et andet site.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Idéen skulle så være, at i og med, man specificerer hvor den ID (eller
> class for den sags skyld) hører til, skal browseren arbejde mindre for
> at finde den i DOMen (tror det er sådan noget lignende).

Hm. OK, det lader til at være misforstået. I hvert fald siger Mozilla

https://developer.mozilla.org/en/Writing_Efficient_CSS

div#id

tager længere tid end

#id

Men om det betyder noget synligt, ved jeg så ikke. Der er vidst ret
stort uenighed blandt de "lærde", om det kan betale sig at gå igennem
sin CSS og optimere på denne måde, som Mozilla anbefaler. Men iøvrigt er
der en del tests for dem, som finder det interessant, rundt om på nettet.

Så vidt jeg kan se på de forskellige udtalelser, skal man dog op i en
del antal "ikke-optimerede" regler, før det kan mærkes som en reel slowdown.



MVH
Rune Jensen

---

Rune Jensen skrev:

> Men om det betyder noget synligt, ved jeg så ikke. Der er vidst ret
> stort uenighed blandt de "lærde", om det kan betale sig at gå igennem
> sin CSS og optimere på denne måde, som Mozilla anbefaler.

Jeg vil på det kraftigste advare mod at tidsoptimere noget som
helst hvis man ikke er spilprogrammør og sidder med tidskritiske
afsnit der skal kodes i assembler, eller med store databaser der
skal betjene mange samtidige brugere.

Skriv filerne så de er så nemme som muligt at læse og rette i for
udenforstående. Det vil man selv sætte pris på den dag man vender
tilbage til noget kode efter et par måneder.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen skrev:
> Rune Jensen skrev:
>
>> Men om det betyder noget synligt, ved jeg så ikke. Der er vidst ret
>> stort uenighed blandt de "lærde", om det kan betale sig at gå igennem
>> sin CSS og optimere på denne måde, som Mozilla anbefaler.
>
> Jeg vil på det kraftigste advare mod at tidsoptimere noget som
> helst hvis man ikke er spilprogrammør og sidder med tidskritiske
> afsnit der skal kodes i assembler, eller med store databaser der
> skal betjene mange samtidige brugere.

Og performance er ikke interessant for f.eks. webshops, så?

Ovenstående med uoptimerede CSS-regler har godt nok intet at sige for
nogensomhelst, maksimum ligger på noget, der ligner 5ms for et worst
case på 750 uoptimerede regler (facebook). Men det fandt jeg så ud af
langt senere, og efter længere søgning og granskning af de forskellige
tests. Jeg vidste det ikke på forhånd, ellers havde jeg skrevet det. Men
performance i sig selv er skam ikke bare "ligegyldigt", heller ikke for
mindre sider. Du skriver om det, som om det er et tabu, man helst skal
holde sig langt væk fra, hvilket jeg simpelthen ikke forstår. Hvorfor
skal det være "store databaser", før performance og tidsoptimering er
interessant? Det er kun 2-3 mennesker i hele verden, det kan have
interesse for, så?

> Skriv filerne så de er så nemme som muligt at læse og rette i for
> udenforstående. Det vil man selv sætte pris på den dag man vender
> tilbage til noget kode efter et par måneder.

Performance på CSS var ikke subject, men et sidespor. Det kom sig af min
(mulige) forklaring til, hvorfor nogen vælger én form for regler, mens
andre vælger en anden, som giver samme resultat. Derfor følte jeg ikke i
første omgang forpligtet til at undersøge nærmere eller underbygge
rigtigheden af drt, men lagde det ud som åbent spørgsmål. Jeg vidste
bare, det havde været diskuteret på et mere seriøst plan, ikke andet.

Og som sagt, selv om nogen altså har interesseret sig nok for det til
både at lave egentlige tests og skrive afhandlinger om det, så har lige
dette med uoptimerede CSS-regler ikke noget at sige. Men lad være med at
tro, at performance generelt er ligegyldigt ting, for det er simpelthen
ikke korrekt. Specielt ikke ved web2.0, hvor AJAX er involveret, eller
ved portaler eller ved webshops. Og sikkert også mange andre steder på
ganske alm. sider. Nedskalering af billeder i browseren er en ganske
alm. forekommende performance-udfordrende (tidskrævende) ting, som nok
alle nybegndere oplever, som eksempel. Det kan virkelig få en side til
at hakke, og jeg vil bestemt ikke sige det er "ligegyldigt", tværtimod.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Nedskalering af billeder i browseren er en ganske
> alm. forekommende performance-udfordrende (tidskrævende) ting, som nok
> alle nybegndere oplever, som eksempel. Det kan virkelig få en side til
> at hakke, og jeg vil bestemt ikke sige det er "ligegyldigt", tværtimod.

Jeg må nok understrege, at jeg er _ikke_ uenig med Bertel i, at det for
langt de fleste kan betale sig at sætte læsbarhed over performance. Og
lige med uoptimeret CSS, er dette netop også, hvad testene viser:

http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/

Der, hvor jeg er uenig, meget uenig, er, at det ikke er interessant for
nybegyndere, begyndere, lettere øvede i det segment at tidsoptimere, for
det er det. Man kan så kalde det noget andet, f.eks. bedre
brugervenlighed, når man eksempelvis skalerer et billede i et
fotoediteringsprogram i stedet for i browseren, eller bruger JPEG til
fotos i stedet for PNG eller GIF, men resultatet vil stadig være en
hurtigere side.

Alle webdesignere kan have gavn af at tænke i tid, for i sidste ende vil
det gavne ens brugere. At tro alle ens brugere sidder på et 20mb, bare
fordi man selv gør, det er ikke smart. Men der er forskelle på, hvor
meget, man skal gå op i de forskellige former for tidsoptimering i
forhold til sidens funktion og i forhold til, hvor avanceret den er,
samt evt. antallet af samtidige brugere. Derfor er det heller ikke alle
"best practises", man behøver følge.

Se f.eks.:
http://developer.yahoo.com/performance/rules.html

Reglen om skalering af billeder samt andre regler for images ligger
iøvrigt næsten nederst.


MVH
Rune Jensen

---

Bertel Lund Hansen wrote:

> Jeg vil på det kraftigste advare mod at tidsoptimere noget som
> helst hvis man ikke er spilprogrammør og sidder med tidskritiske
> afsnit der skal kodes i assembler, eller med store databaser der
> skal betjene mange samtidige brugere.

Læste du den artikel Rune linkede til?

Så vidt jeg kan udlede, så omhandler den god kodeskik, og best practice, og
ikke enkelte optimeringer.

Hvis man starter med at indarbejde god kodeskik, giver det bedre
performance, og vel at mærke _uden_ at bruge tid på enkeltoptimeringer.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Hvis man starter med at indarbejde god kodeskik, giver det bedre
> performance, og vel at mærke _uden_ at bruge tid på enkeltoptimeringer.

Mozilla taler om Best Practise, som vel er noget, man ved, *inden* man
starter på sit arbejde, mens testene og også konklusionen på de test
beskægtiger sig med de best practises i forb. med optimering. Det er
faktisk to forskellige måder at se det på, hvilket nok også forvirrede
mig, for optimering forudsætter jo, at arbejdet *er* lavet, og at man
først her begynder at kigge på at forbedre koden.

Her er konklusionen meget klar, at som optimeringsmodel, der kan disse
Best Practise ikke anbefales - man får simpelthen nul ud af det set i
forhold til det man vil vinde ved at optimere ved andre ting i stedet,
f.eks. ukritisk brug af :hover (ikke nærmere underbygget, men det står der).

Men... som du skriver, hvis de Best Practise er indarbejdet fra start,
så vil alt hvad man tjener være ganske gratis derefter. Også selv om det
kun er 5 ms. Hvis jeg kan få 5 ms ganske gratis uden at gøre noget
ekstra arbejde, men simpelthen fordi jeg har den viden, så vil jeg da
gøre det...

Jeg har forstået de første regler, så. Men en del af det er simpelthen
gibberish for mig, desværre, f.eks. under inheritanse. XUL og RDF siger
mig mindre end intet, bortset fra, det første vidst er noget intern
joking med Ghostbusters.


MVH
Rune Jensen

---

Rune Jensen wrote:

> for optimering forudsætter jo, at arbejdet *er* lavet, og at man
> først her begynder at kigge på at forbedre koden.

Nej, hvis man fra start tænker i optimerede banewr, og faktisk også let
læselige, så vil resultatet automatisk være optimeret kode.

> XUL og RDF siger
> mig mindre end intet, bortset fra, det første vidst er noget intern
> joking med Ghostbusters.

Tænker du på ZUUL?

XUL er 'yet another language', som om vi ikke har nok.
Tænk hvis vi havde lige så mange varianter over HTML, som der er varianter
over sprog.

--
Med venlig hilsen
Stig Johansen

---

Jahirah wrote:
> Jeg synes det er pinligt at spørge om, men jeg har aldrig rigtig
> lært det grundliggende i CSS og derfor føler jeg mig lidt nød til
> at spørge, bl.a for at opnå bedre forståelse.
>
> Hvad er forskellen på div#ID og #ID?
>
> Hver side kan kun have 1 element pr. ID ifølge standarderne.
> Men jeg kan ikke rigtig sætte en finger på om der er forskellen
> på brugen af div#ID og #ID.

Man kan betragte det sådan, at hvis du i css skriver div#id for at tilpasse
en bestemt div på en side, afskærer du dig selv fra at bruge samme
css-definition på f.eks. en p på en anden side.

Hvis du derimod i css nøjes med at skrive #id, kan du på enhver side selv
vælge hvilket element, der skal have den pågældende definition.

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk