Forum Mjukvara Programmering och digitalt skapande Tråd

Hur dåligt att ha för många CSS-selektorer ?

1
Skriv svar
Permalänk
Avstängd
●

Hur dåligt att ha för många CSS-selektorer ?

Hej,
Hur dåligt är det att vara för tydlig när man selektar i CSS?

Bilden i följande html

<img id="bild" class="2014" src="http://www.microsoft.com/image.jpg">

kan selektas på flera sätt, bl.a.:

img
img#bild
#bild
.2014
img#bild.2014

Ibland är jag övertydlig när jag skriver CSS med mer komplicerad struktur än den ovan; jag väljer att skriva img#bild.2014 helt enkelt för att det blir lättare att hålla isär selektorer och hitta rätt i koden. Men så stötte jag på nån i ett forum som sa:

Citat:

"don't use the tagNames in your selectors. #content.myClass is faster than div#content.myClass because the tagName adds a filtering step that you don't need. Use tagNames in selectors only where you must!"

Hur pass relevant är detta råd i våra dagar med snabba processorer och ständigt större bandbredd?

Redigera
Citera flera Citera
Permalänk
Avstängd
●

Mindre relevant men fortfarande relevant skulle jag säga.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Beror helt på storleken och dylikt.
Försök alltid sträva efter att vara tydlig i förstahand, benchmarka efter om det skulle bli relevant.

Jag skulle tippa på att det är knappt märkbart i mindre projekt och dylikt i dagens läge.

Visa signatur

Corsair 16GB (4x4096MB) CL9 1600Mhz | Asus P8Z77-V PRO |
Samsung SSD Basic 830-Series 256GB | Intel Core i7 3770K 3,5Ghz |
Asus Xonar Essence STX | Noctua NH-U9B SE2 | Antec Performance One P280 | Corsair HX 850W 80+ Gold Modulär | MSI GTX 770

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag skulle ändå vilja påstå att det är ganska viktigt att tänka sig för lite när man skriver selektorer. I dagens webb delas oftast sidor mellan desktop datorer och telefoner och allt däremellan. Genom att ha en slimmad och enkel css kan du spara många millisekunder. Även om du har en snabb telefon så har kanske inte din kund det.

* Skippa # selektorer om du kan, i vissa fall måste man ha det men det är oftast få.
* Försök att hålla selektor djupet mindre än 3-4 steg. Mest för din egna skull, annars kan du stöta på specificitetsproblem.
* Försök att hitta en bra naming-convention som funkar för din sida. Ett exempel är att man delar upp sidan i regioner och nämner cssen som tillhör det så att man förstår och får kontext.

typ.
.header-Logotype
.header-Title
.header-SubTitle

Redigera
Citera flera Citera
Permalänk
Medlem
●

I sammanhanget kan jag tipsa denna artikeln av Mozilla, Writing efficient CSS

Rätt intressant citat från ovanstående länk:

Citat:

The descendant selector is the most expensive selector in CSS. It is dreadfully expensive—especially if the selector is in the Tag or Universal Category.

Frequently, what is really desired is the child selector. For instance, the performances are so bad, that descendant selectors are banned in Firefox' User Interface CSS, without a specific justification. It's a good idea to do the same on your Web pages

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●

Det är ofta tecken på ett (kodmässigt) designproblem om man behöver använda väldigt utförligt specificerade selektorer. En stor poäng med CSS är att enkelt kunna återanvända och kombinera stilar, men om man behöver skriva närapå en separat deklaration till varenda liten del så har man troligen inte abstraherat sina klasser på rätt nivå. Det är också ett gissel att fastna i en brottningsmatch med specificitetsreglerna i CSS, vilket man lätt kan göra om man upprepat använder överkvalificerade selektorer.

För att hitta i din fil så fungerar kommentarer och tydlig struktur bättre. Är man orolig över filstorlek så bör man titta på minifieringsrutiner av både JavaScript och CSS.

Det finns även en stor rörelse som helt avråder från att någonsin använda ID-taggar som selektorer i CSS, till förmån för klasser. Är man van vid #-selektorn så låter det kanske till en början konstigt, men det finns en intressant poäng i att ID-attributet egentligen inte rimmar med CSS-konceptet vad gäller återanvändbarhet och annat. Genom att som grundregel inte använda det för detta så undviker man att tänka "fel" även i andra situationer. ID-attributet är däremot fundamentalt för interaktivitet på sidor via exempelvis JavaScript.

En relaterad anledning till att inte använda ID-attributet i CSS är hur det gör att man sammanflätar saker som anchornavigering och JavaScriptmetoder med CSS: om man vill omfaktorera sina JavaScript eller ändra navigeringen så att det även ändrar ID-attributen så behöver man kanske helt plötsligt även ändra i sitt CSS, och vice versa, om man blandat in element-ID i stilmallen. Det är en konceptuellt onödig koppling.

Minns att jag samlade lite länkar i ämnet i ett annat inlägg på forumet tidigare detta år (den första länken är rätt uttömmande på egen hand):

Skrivet av phz:

Jag är inte den som försvarar Vbulletin , men vad gäller avsaknad av ID-attribut så är det en generell och vanligt använd teknik att enbart, utan undantag, använda klasser till CSS-ändamål. I stället för att flika ut för mycket i denna tråd så länkar jag till diskussioner som redan varit, på bloggar och annat:

ID har mening vad gäller att kunna adressera ett specifikt element via exempelvis JavaScript eller som länkankare, men konceptet med "unikt element" bär egentligen ingen mening när det gäller CSS. Däremot så har det nackdelen att det ökar komplexiteten i prioritetsbestämmandet i CSS, vilket kan leda till en ordentlig djungel av `!important` och annat i större projekt, vilket genererar gråa utvecklarhår.

Utan att ta ställning för att detta skulle vara "rätt" (och det stack en del i mina ögon första gången jag såg det själv ) så är det väl starkt att säga att det är "fel" att inte använda ID-attribut överallt där man måhända kan.

Gå till inlägget
Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara