Share
I tilfelle du ikke la merke til, mottok CSS analysesiden cssstats.com nylig. Det er et vakkert designet verktøy som gir deg mye objektiv innsikt i koden din, men hvordan kan du mest mulig utnytte CSS-statistikken? Hva skal du skyte for? Hva mener de, og hvordan kan du bruke dem dag til dag?
I dag skal vi snakke om CSSs beste praksis, spesifisitet og vedlikehold, og du lærer hvordan du skal tolke og utnytte CSS-statistikken bedre. La oss dykke inn!
Hodet på over til cssstats.com, skriv inn enten webadressen din, stilarket eller lim den røde CSS direkte inn i tekstområdet nederst og trykk Gå.
Når du har analysert, får du massevis av statistikk om CSS; fra antall reglene som brukes, deres gjennomsnittlige størrelse, sammenbrudd av hver type deklarasjon, skrift- og bakgrunnsfarger, skriftfamilier og -størrelser og spesifisitetsgrafer.
Det er hva CSS Stats gir deg, nå la oss se på hva vi kan gjøre med alle dataene.
Som front-end-utviklere er vi hele tiden bekymret for ytelse og brukeropplevelse. Vi er også ansvarlige for å bygge programvare, men ordet "programvare" er fremmed for mange front-end-utviklere som kommer fra en designbakgrunn. Det er ofte enkelt å ignorere beste praksis når vi koder vårt CSS.
Men sannheten er at front-end-utvikling, akkurat som enhver annen programvareutvikling, krever fokus på beste praksis. Reglene for beste praksis diskuteres rikelig på nettet, men for denne artiklens skyld skal vi finpusse på hva som uten tvil er den viktigste praksisen når det gjelder CSS: vedlikeholdsevne.
Vedlikehold av CSS senterer på mange forskjellige fasetter.
Vi vil ikke dykke inn i hvert av disse elementene individuelt, men når vi snakker om vedlikeholdsevne, påvirker hvert av disse overordnet den generelle vedlikeholdsegenskapen til kodebase.
Det ærlige svaret? Ingenting, nødvendigvis. Du lærer ikke noe om vedlikeholdsevne ved å bare se på CSS-statistikk. Du må også forstå konteksten til det aktuelle CSS, samt konteksten av aktiv utvikling.
Den første måten å analysere CSS-statistikken på er å lete etter tegn på CSS-oppblåsthet.
Av Oppblåst vi mener ubrukt, overflødig eller ellers unødvendig CSS.
La oss ta for eksempel et ensiders program som har fem forskjellige innholdsmoduler. Hva slags CSS-statistikk vil du forvente at en enkelt side skal ha? Et typisk enkelttsidsprogram kan ha en brøkdel av antall CSS-regler og kanskje halvparten av antall fargedeklarasjoner som et stort nyhetsutgivelsessted eller en mangesidig SAAS-applikasjon.
Hvis du ser et enormt antall selektorer (for eksempel hvis ditt enkle enkelttsides nettsted inneholder så mye CSS som et nettramme som Bootstrap, som klokker på bare under 2400 selectors), er det sannsynlig at du har gått galt et sted . Hvis du laster inn i 30 skriftstørrelser og designet ditt ringer til 10, er det sannsynlig at du har ubrukte, oppblåste stiler eller muligens inkonsekvente stiler.
Et mulig unntak fra denne regelen, som det gjelder vedlikehold, er hvis du er faktisk bruker Bootstrap eller et annet populært, godt dokumentert rammeverk; fordi dokumentasjonen på disse prosjektene er relativt dyp og bruken har mettet nettet, gjør ikke frontend utviklere det nødvendigvis holde Bootstrap, så lenge primærkilden beholder Bootstraps kjernedrifter. Men hvis du inkluderer Bootstrap-rammen bare for nettverket eller noen få brukergrensesnitt, bør du i stedet bygge en tilpasset versjon som ikke inkluderer det ekstra CSS som du aldri planlegger å bruke.
Det er mulig at søknaden din gjør noe som krever et stort antall selektorer, farger eller skriftstørrelser. Hvis du for eksempel kjører en nettbutikk som bruker produktfarger, er det mulig at et stort antall farger kan dukke opp i ditt CSS og være et helt legitimt tilfelle. Et annet eksempel er at du kjører et nettsted som lar brukerne velge fra en liste over skriftstørrelser og skrifttyper for innhold de lager. I disse eksemplene er det fornuftig å se store tall i de aktuelle kategoriene.
Medium.com bruker en skriftstørrelse på 301px et sted ... Men hvis du oppretter noe som for eksempel en blogg med et begrenset fargevalg, bør CSS-statistikkene gjenspeile fargevalg og skriftdeklarasjons telling.
Definerer du den samme skriftstørrelsen tjue ganger over ditt CSS? Svært ofte kan dette unngås, og er vanligvis et resultat av mangel på planlegging. Hvis du bestemmer skriftstørrelsene dine før du skriver andre CSS, vil du lettere kunne bruke disse størrelsene over resten av systemet.
Det samme gjelder for enhver gjentatt stil; hvis du finner deg selv å skrive det samme flere ganger, kanskje det sett med stiler fortjener sin egen presentasjons- eller semantisk klasse eller annen modulær definisjon?
Ikke gå over bord her; omdefinere noen skriftstørrelser eller bakgrunnsfarger er ikke en stor avtale. Men omdefinere flere stilarter flere ganger på svært liknende moduler kan bety at du skal utvide en baseklasse. For eksempel, hvis du har en knappeklasse:
.btn font-size: 1.2em; font-weight: 400; brevavstand: .06em; farge: #fff; bakgrunnsfarge: # 4a4a4a; polstring: 6px 8px;
Si at du vil ha en blå versjon av den samme knappen. Hvordan skal du gå om å definere det? Hvis du omdefinerer det samme btn klasse, ville det se slik ut:
.btn-blå font-size: 1.2em; font-weight: 400; brevavstand: .06em; farge: #fff; bakgrunnsfarge: # 0C508D; polstring: 6px 8px;
Selvfølgelig er det mange problemer med dette. Først bryter det mot DRY (ikke repeter selv) prinsippet. Men hvorfor betyr det noe? vedlikeholdbarhet. La oss for eksempel si at designet endres og krever en mindre skrift på knapper. Du må da gå inn i .btnog de .btn-blå klasse for å endre skriftstørrelsen. Enda mer komplikasjon oppstår når du trenger varianter av de blå og vanlige gråknappene, som en blå versjon. Alle endringene dine til en knapp må gjøres på mange knapper.
Dette er utrolig ineffektivt. I stedet bør du dra nytte av det faktum at klassene er modulære, og lar deg definere knappestiler som utvider basen din .btn klasse.
.btn font-size: 1.2em; font-weight: 400; brevavstand: .06em; farge: #fff; bakgrunnsfarge: # 4a4a4a; polstring: 6px 8px; .btn.btn-blue bakgrunnsfarge: # 0C508D;
Aha! Og nå har vi en mye mer vedlikeholdsbar løsning, som også fjerner et betydelig antall linjer med CSS og følger DRY-prinsippet.
Specificitet er et av de vanskeligere å forstå mørke hjørner av CSS som ofte går opp selv de mest erfarne utviklerne. På CSS-statistikk kan du se et spesifikkhetsdiagram som viser hvor spesifikk selektoren er i ditt CSS, så vel som hvor de velgerne dukker opp.
CSS spesifisitet fra BBCs nettstedDenne grafen viser spesifisiteten til selektorer som de opplever i CSS fra bbc.co.uk. Tenk på venstre side av grafen er toppen av stilarket, så beveger den seg langs x-akse som det leser ned stilarket. Jo mer spesifikt regelen er, desto høyere er den mørkeblå linjen på y-aksen.
Vi gir tre generelle "tommelfingerregler" for å starte med, og deretter forklare reglene.
Vi snakker om hver av disse mer i dybden, men først la oss snakke litt om hvordan spesifisitet fungerer.
CSS-selektorer blir tildelt en spesifisitetspoeng for å informere nettleserenes gjengemotor hvilke regler gjelder for hvilke elementer. Årsaken til at dette er nødvendig er også grunnen til at CSS er så kraftig: Stiler kan arves og cascaded i CSS. Dette betyr at du kan bruke mer enn ett sett med stiler til et gitt element. Avkastningsmotoren må konsolidere alle disse reglene og presentere noe, men hva skjer når to forskjellige verdier er angitt for samme stildeklarasjon? For eksempel:
en farge: #fff; a.button farge: # 000;
Når CSS-motoren møter en tag med en klasse av knapp, Det må avgjøre om farge attributtet skal være #fff, # 000, eller nettleserens standard. CSS-spesifisitet er regelen som nettleseren bruker for å gjøre denne bestemmelsen.
Så, hvordan fungerer spesifisitet? Bruk dette scoring systemet som en guide, tatt direkte fra CSS Tricks:
Accentsconagua
!viktig trumper dem alle* selektorer får en spesifisitetspoengsum på alle 0s.Vær oppmerksom på at i dette scoring-systemet, når noe går over 10, går det ikke inn i neste kolonne, for eksempel hvis du hadde en selector som var 11 elementer lang, ville det ikke spyle over for å være en spesifisitet på 0, 0,1,1. Det vil i stedet være 0,0,0,11.
Her er noen selektorer og deres resultatresultater.
nav li a / * 0,0,0,3 * / .nav-element / * 0,0,1,0 * / nav .nav-item / * 0,0,1,1 * / #logo / * 0,1,0,0 * /
en bakgrunnsfarge: blå! viktig; / * I det forrige eksempelet brukte vi inline-stiler for å sette bakgrunnsfargen til rød. Men hvis vi brukte denne stilen med den viktige kvalifiseringen, ville den overstyre inline-stilen. * /
Ok, nå, når vi har en grunnleggende grunnlag for CSS-spesifisitet, hvordan skal det påvirke vår kode? La oss gå tilbake til våre tre tommelfingerregler for CSS-spesifisitet.
Denne regelen fastslår i hovedsak at generelle selektorer skal være i begynnelsen av CSS, og mer bestemte selektorer skal komme senere i CSS. Årsakene til denne regelen er mange.
Først plasserer du generelle regler i begynnelsen av søknaden din, vanligvis sett i koden din for grunnleggende moduler som skal opprettes. I forbindelse med # 2 har de minste spesifikke stilene i begynnelsen, at du skriver først med minst spesifisitet. Senere, ettersom koden din utvikler seg, kan det hende at å legge til mer spesifikke stiler, blir nødvendig for å overstyre eller forlenge tidligere stiler.
Stil på Apples nettside er tungt spesifikk tidlig på stilarket
Den rene CSS-rammeverkets spesifisitet øker vanligvis mot slutten av stilarketDette fører til vårt andre punkt: Hva skjer når CSS-gjengemotoren møter to selektorer som har samme score? Det har fortsatt å velge, så det vil velge den sistnevnte av de to reglene. Ved å feile til minst spesifikk i begynnelsen av filen, sikrer du at spesifisitetsoverskridelsene dine er mer spesifikke når du går senere inn i filen. Dette betyr at en enkelt klasse senere i filen bør anses for å kunne overstyre enkeltklasser tidligere i filen.
Denne praksisen vil sikre at senere utvikling på samme prosjekt raskt kan forstå kaskadesystemet.
Hvis du har vært en front-end-utvikler for lenge, har du sannsynligvis opplevd "CSS-spesifisitetskrigen". Du skriver en velger og noen få regler, og oppdater deretter nettleseren for å finne at endringene ikke har blitt brukt. Du vet fra tidligere prosjekter eller fra samtaler om spesifisitet at det er fordi selgeren din ikke er spesifikk nok, så i stedet for å prøve å spore problemet til selektoren som er for spesifikk, bestemmer du deg for å lage den nye mer spesifikk. Du legger til en ID eller to, og hvis det ikke gjør trikset, kaster du bare !viktig på det. Og, voila - dine stiler dukker opp.
Denne tilnærmingen fungerer, teknisk sett; men uansett, når du ønsker å forlenge den stilen, må du fortsette å øke kompleksiteten, og før du vet det, er seleksjonene dine ekstremt spesifikk, og du må gjenta koden i stedet for å bare gjenbruke klasser. På toppen av det er det nesten umulig å avgjøre nøyaktig hvilket nivå av spesifisitet noen nye stiler burde ha uten å legge til flere og flere IDer og !viktig erklæringer.
Å holde selektorer mindre spesifikke er en mye bedre og mer vedlikeholdsbar måte å håndtere CSS på.
Denne regelen er primært på plass for å unngå merkelige regler. Hvis du for eksempel definerer noen klasser for tekstpresentasjon, og plutselig har en regel som hekker seks klasser og en ID, bør den aktuelle regelen plasseres kontekst med mer bestemte selektorer det er relatert til.
CSS-statistikken kan gi deg innsikt i hvordan CSS er skrevet, men dette er bare nyttig hvis du har en ide om hva denne statistikken skal se ut før du prøver å analysere dem. Dette betyr at du har en dyp kontekstuell forståelse av hvordan CSS er skrevet og hvorfor. Hvis CSS er vedlikeholdt og passende for nettstedet det brukes på, er statistikken til det CSS ikke grunn nok til å refactor koden din.
I stedet for å følge nummerreglene blindt, som en ansvarlig utvikler for framsiden, bør du fokusere på å gjøre koden din vedlikeholdsbar og redusere oppblåsthet. Statistikk om koden din kan hjelpe deg med å finne problemområder, men de kan bare gå så langt.
