Share
Om du inte märkte, fick CSS analys webbplats cssstats.com nyligen en översyn. Det är ett vackert utformat verktyg som ger dig mycket objektiv inblick i din kod, men hur kan du göra den bästa användningen av CSS-statistiken? Vad ska du skjuta för? Vad menar de, och hur kan du använda dem dag-till-dag?
Idag ska vi prata om CSS bästa praxis, specificitet och underhåll, plus du lär dig hur du korrekt tolkar och utnyttjar CSS-statistiken bättre. Låt oss dyka in!
Huvud på över till cssstats.com, ange antingen webbadressen till din webbplats, dess stylesheet eller klistra in den råa CSS direkt i textområdet längst ner och träffa Gå.
När du har analyserat, får du massor av statistik om CSS; från antalet använda regler, deras genomsnittliga storlek, uppdelningar av varje typ av deklaration, typsnitt och bakgrundsfärger, typfamiljer och storlekar och specificitetsgrafer.
Det är vad CSS-statistik ger dig, nu ska vi titta på vad vi kan göra med all data.
Som front-end-utvecklare är vi ständigt oroade över prestanda och användarupplevelse. Vi är också ansvariga för att bygga programvara, men ordet "programvara" är främmande för många front-end-utvecklare som kommer från en designbakgrund. Det är ofta lätt att ignorera bästa praxis när vi kodar vår CSS.
Men sanningen är att front-end-utveckling, precis som vilken som helst annan mjukvaruutveckling, kräver att man fokuserar på bästa praxis. Reglerna för bästa praxis diskuteras rikligt på webben, men för den här artikelns skull kommer vi att fästa in på vad som förmodligen är den viktigaste praxisen när det gäller CSS: maintainability.
Hållbarheten hos CSS centrerar på många olika aspekter.
Vi kommer inte att dyka in i var och en av dessa objekt individuellt, men när vi pratar om underhållbarhet påverkar var och en av dessa överväganden den totala underhållsförmågan för din kodbas.
Ärligt svar? Ingenting, nödvändigtvis. Du lär dig inte något om underhållsförmåga genom att bara titta på CSS-statistiken. Du måste också förstå sammanhanget för den specifika CSS, liksom kontexten för aktiv utveckling.
Det första sättet att analysera din CSS-statistik är att leta efter tecken på CSS bloat.
Av svälla vi menar oanvänd, överflödig eller på annat sätt onödig CSS.
Låt oss exempelvis ta ett ensidigt program som har fem olika innehållsmoduler. Vilken typ av CSS-statistik skulle du förvänta dig att en enda sida skulle ha? En typisk enkeltsidesapplikation kan ha en bråkdel av antalet CSS-regler och kanske hälften av antalet färgdeklarationer som en stor nyhetspubliceringssida eller en mångfacetterad SAAS-applikation.
Om du ser ett enormt antal selektörer (till exempel om din enkla enkelsidiga webbplats innehåller så mycket CSS som ett webbramverk som Bootstrap, som klickar på knappt 2400 selektörer) är det troligt att du har gått fel någonstans . Om du laddar i 30 teckenstorlekar och din design kräver 10, är det troligt att du har oanvända, uppblåsta stilar eller eventuellt inkonsekventa stilar.
Ett eventuellt undantag från denna regel, när det gäller hållbarhet, är om du är faktiskt med Bootstrap eller annan populär, väl dokumenterad ram Eftersom dokumentationen på dessa projekt är relativt djup och användningen har mättat på webben, behöver inte utvecklare av framsidan nödvändigtvis upprätthålla Bootstrap, så länge som den primära källan bibehåller Bootstraps kärnanpassningar. Om du däremot inkluderar Bootstrap-ramverket helt enkelt för rutnätet eller några UI-element, borde du istället bygga en anpassad version som inte innehåller den extra CSS som du aldrig planerar att använda.
Det är möjligt att din ansökan gör något som kräver ett stort antal väljare, färger eller teckenstorlekar. Om du till exempel kör en webbutik som använder produktfärger är det möjligt att ett stort antal färger kan dyka upp i din CSS och vara ett helt legitimt fall. Ett annat exempel är om du kör en webbplats som tillåter användare att välja från en lista med teckensnittstorlekar och teckensnitt för innehåll de skapar. I dessa exempel är det meningsfullt att se stora siffror i de specifika kategorierna.
Medium.com använder en fontstorlek på 301px någonstans ... Om du skapar något som till exempel en blogg med ett begränsat färgschema, bör dina CSS-statistik återspegla det val av färgval och typsnitt som deklarerar.
Definierar du samma typsnittstyp tjugo gånger över din CSS? Mycket ofta kan detta undvikas, och är vanligtvis ett resultat av brist på planering. Om du bestämmer dina teckenstorlekar innan du skriver någon annan CSS, kommer du lättare att kunna tillämpa dessa storlekar över resten av systemet.
Detsamma gäller för någon upprepad stil; om du befinner dig att skriva samma sak flera gånger, förtjänar den uppsättningen stilar för egen presentation eller semantisk klass eller annan modulär definition?
Gå inte överbord här; omdefiniera några teckenstorlekar eller bakgrundsfärger är inte en stor sak. Men omdefiniera ett antal stilar flera gånger på mycket liknande moduler kan innebära att du borde förlänga en basklass. Om du till exempel har en knappklass:
.btn font-size: 1.2em; font-vikt: 400; brevavstånd: .06em; färg: #fff; bakgrundsfärg: # 4a4a4a; vaddering: 6px 8px;
Säg att du vill ha en blå version av samma knapp. Hur ska du gå om att definiera det? Om du omdefinierar detsamma BTN klass skulle det se ut så här:
.btn-blå font-size: 1.2em; font-vikt: 400; brevavstånd: .06em; färg: #fff; bakgrundsfärg: # 0C508D; vaddering: 6px 8px;
Självklart finns det många problem med detta. För det första strider det mot principen DRY (repetera inte). Men varför spelar det roll? underhåll. Låt oss exempelvis säga att designen ändras och kräver en mindre typsnitt på knappar. Då måste du gå in i .BTNoch de .BTN-blue klass för att ändra teckenstorleken. Ännu mer komplikation uppstår när du behöver varianter av de blå och vanliga grå knapparna, som en blå version. Alla dina ändringar till någon knapp måste göras på många knappar.
Detta är otroligt ineffektivt. Istället borde du dra nytta av det faktum att klasserna är modulära och låter dig definiera knappstilar som utökar din bas .BTN klass.
.btn font-size: 1.2em; font-vikt: 400; brevavstånd: .06em; färg: #fff; bakgrundsfärg: # 4a4a4a; vaddering: 6px 8px; .btn.btn-blue background-color: # 0C508D;
A ha! Och nu har vi en mycket mer underhållbar lösning, som också tar bort ett betydande antal rader av CSS och följer DRY-principen.
Specificitet är en av de svårare att förstå mörka hörn av CSS som ofta går upp även de mest erfarna utvecklarna. På CSS-statistik kan du se ett specificitetsschema som visar hur specifika selektorerna är i din CSS, samt där de väljare ser upp.
CSS-specificitet från BBC: s webbplatsDenna graf visar specificiteten hos väljare som de upplever i CSS från bbc.co.uk. Tänk dig att vänster om diagrammet är toppen av stilarket, då rör det sig längs x-axeln som det läser ner stilarket. Ju mer specifika regeln är desto högre är den mörkblå linjen på y-axeln.
Vi ska ge tre allmänna "tumregler" att börja med och förklara sedan reglerna.
Vi pratar om vart och ett av dessa mer djupt, men först låt oss prata lite om hur specificitet fungerar.
CSS-selektorer tilldelas en specificitetspoäng för att informera webbläsarens återgivningsmotor vilka regler gäller för vilka element. Anledningen till att detta behövs är också orsaken till att CSS är så kraftfull: stilar kan vara ärftliga och kaskad i CSS. Det betyder att du kan tillämpa mer än en uppsättning stilar på ett visst element. Återgivningsmotorn måste konsolidera alla dessa regler och presentera något, men vad händer när två olika värden är inställda för samma stildeklaration? Till exempel:
en färg: #fff; a.knapp färg: # 000;
När CSS-motorn möter en tagg med en klass av knapp, Det måste avgöra om Färg attribut ska vara #fff, # 000, eller webbläsarens standard. CSS-specificitet är den regelsätt som webbläsaren använder för att bestämma denna.
Så hur fungerar specificitet? Använd detta poängsystem som en guide, taget direkt från CSS Tricks:
Accentsconagua
!Viktig trummar dem alla* selektorer får en specificitetspoäng på alla 0s.Observera att i det här poängsystemet, när något går över 10, går det inte in i nästa kolumn, så till exempel om du hade en väljare som var 11 element lång så skulle det inte spillas över för att vara en specificitet på 0, 0,1,1. Det skulle istället vara 0,0,0,11.
Här är några väljare och deras resultat.
nav li a / * 0,0,0,3 * / .nav-item / * 0,0,1,0 * / nav.nav-item / * 0,0,1,1 * / #logo / * 0,1,0,0 * /
en bakgrundsfärg: blå! viktig; / * I föregående exempel använde vi inline-stilar för att ställa in bakgrundsfärgen till röd. Om vi tillämpade den här stilen med den viktiga kvalifikationen, skulle den dock åsidosätta inline-stilen. * /
Okej - nu när vi har en grundläggande primer ur vägen för CSS-specificitet, hur ska det påverka vår kod? Låt oss gå tillbaka till våra tre tumregler för CSS-specificitet.
Denna regel säger i huvudsak att allmänna väljare ska vara i början av din CSS, och mer specifika väljare bör komma senare i din CSS. Anledningen till denna regel är många.
Först ställer du allmänna steg i början av din ansökan vanligtvis scenen i din kod för grundläggande moduler som ska skapas. I samband med # 2 har de minst specifika stilar i början att du skriver med minst specificitet möjligt först. Senare, när din kod utvecklas kan det vara nödvändigt att lägga till mer specifika stilar för att åsidosätta eller utöka tidigare stilar.
Styles på Apples hemsida är mycket specifika tidigt i stilarket
Den rena CSS-ramens specificitet ökar i allmänhet mot slutet av stilarketDetta leder till vår andra punkt: vad händer när CSS-återgivningsmotorn möter två väljare som har samma poäng? Det måste fortfarande välja, så det kommer att välja den senare av de två reglerna. Genom att erra till minst specifikt i början av filen ser du till att dina specificitetsöverträdelser är mer specifika när du går senare i filen. Det innebär att en enda klass senare i filen bör anses kunna överväga enskilda klasser tidigare i filen.
Denna praxis kommer att se till att senare utveckling på samma projekt snabbt kan förstå kaskadsystemet.
Om du har varit en front-end-utvecklare för länge har du förmodligen upplevt "CSS-specificitetskriget". Du skriver en väljare och några regler, uppdatera sedan bara webbläsaren för att hitta ändringarna inte har tillämpats. Du vet från tidigare projekt eller från konversationer om specificitet att det beror på att din väljare inte är tillräckligt specifik, så istället för att försöka spåra problemet till den väljare som är för specifik, bestämmer du dig för att göra den nya Mer specifik. Du lägger till ett ID eller två, och om det inte gör tricket, kastar du bara !Viktig på det. Och, voila - dina stilar visas.
Denna metod fungerar tekniskt sett. men tyvärr, helst du vill utvidga den stilen, måste du fortsätta att öka komplexiteten, och innan du vet är dina selektorer ytterst specifikt, och du måste upprepa kod snarare än att bara återanvända klasser. Utöver det är det nästan omöjligt att bestämma exakt vilken nivå av specificitet några nya stilar borde ha utan att lägga till fler och fler ID och !Viktig deklarationer.
Att hålla dina väljare mindre specifika är ett mycket saner, mer underhållbart sätt att hantera din CSS.
Denna regel är i första hand på plats för att undvika otroligt placerade regler. Om du till exempel definierar vissa klasser för textpresentation och plötsligt har en regel som hyllar sex klasser och ett ID, bör den specifika regeln placeras kontextuellt med mer specifika väljare, den är relaterad till.
CSS-statistiken kan ge dig inblick i hur din CSS skrivs, men det här är bara användbart om du har en uppfattning om vad den statistiken ska se ut innan du försöker analysera dem. Detta innebär att du har en djup kontextuell förståelse för hur din CSS skrivs och varför. Om din CSS är underhållbar och lämplig för den webbplats den används på, är statistiken för den CSS inte tillräckligt för att refactor din kod.
I stället för att följa numren regler blint, som ansvarig front-end-utvecklare, bör du fokusera på att göra din kod underhållbar och minska uppblåsthet. Statistik om din kod kan hjälpa dig att hitta problemområden, men de kan bara gå så långt.
