Share
In het geval dat u het niet opmerkt, ontving de CSS-analysesite cssstats.com onlangs een revisie. Het is een prachtig ontworpen hulpmiddel dat u veel objectief inzicht in uw code geeft, maar hoe kunt u het beste gebruik maken van CSS-statistieken? Waar zou je op moeten schieten? Wat bedoelen ze en hoe kun je ze dagelijks gebruiken??
Vandaag gaan we het hebben over CSS-best practices, specificiteit en onderhoudbaarheid, plus u leert hoe u CSS-statistieken correct kunt interpreteren en beter kunt gebruiken. Laten we erin duiken!
Ga naar cssstats.com, voer de url van uw website in, het stylesheet of plak de onbewerkte CSS rechtstreeks in het tekstgebied onderaan en druk op Gaan.
Eenmaal geparst, krijgt u een hoop statistieken over de CSS; van het aantal gebruikte regels, hun gemiddelde grootte, uitsplitsingen van elk type aangifte, lettertype en achtergrondkleuren, lettertypefamilies en -groottes en specificiteitsgrafieken.
Dat is wat CSS Stats je geeft, laten we nu kijken naar wat we kunnen doen met alle gegevens.
Als front-end ontwikkelaars zijn we constant bezorgd over de prestaties en gebruikerservaring. We zijn ook verantwoordelijk voor het bouwen van software, maar het woord 'software' is een vreemde taal voor veel front-end ontwikkelaars die afkomstig zijn van een ontwerpachtergrond. Het is vaak eenvoudig om best practices te negeren wanneer we onze CSS coderen.
De waarheid is echter dat de ontwikkeling van de front-end, net als bij elke andere software-ontwikkeling, gericht moet zijn op best practices. De regels voor best practices worden overvloedig besproken op het web, maar in het belang van dit artikel gaan we blikken doen op wat misschien wel de belangrijkste praktijk is met betrekking tot CSS: onderhoudbaarheid.
De onderhoudbaarheid van CSS-centra op veel verschillende facetten.
We zullen niet elk afzonderlijk duiken, maar als we het hebben over onderhoudbaarheid, heeft elk van deze overwegingen gevolgen voor de algehele onderhoudbaarheid van uw codebasis..
Het eerlijke antwoord? Niets, noodzakelijkerwijs. U leert niets over onderhoudbaarheid door simpelweg naar CSS-statistieken te kijken. Je moet ook de context van die specifieke CSS begrijpen, evenals de context van actieve ontwikkeling.
De eerste manier om uw CSS-statistieken te analyseren, is op zoek te gaan naar tekenen van CSS-zwelling.
Door zwellen We bedoelen ongebruikte, overtollige of anderszins onnodige CSS.
Laten we bijvoorbeeld een toepassing van één pagina maken met vijf verschillende inhoudsmodules. Welke soorten CSS-statistieken zou u van een enkele pagina verwachten? Een typische toepassing van één pagina bevat mogelijk een fractie van het aantal CSS-regels en misschien de helft van het aantal kleurverklaringen als een grote nieuwspublicatiesite of veelzijdige SAAS-toepassing.
Als u een enorm aantal selectors ziet (bijvoorbeeld als uw eenvoudige single-page-site evenveel CSS bevat als een web framework zoals Bootstrap, dat klokt op iets minder dan 2.400 selectors), is het waarschijnlijk dat u ergens verkeerd bent gegaan . Als u in 30 lettergroottes laadt en uw ontwerp om 10 vraagt, hebt u waarschijnlijk ongebruikte, opgeblazen stijlen of mogelijk inconsistente stijlen.
Een mogelijke uitzondering op deze regel is, als het gaat om onderhoudbaarheid, als dat zo is werkelijk gebruikmakend van Bootstrap of een ander populair, goed gedocumenteerd raamwerk; omdat de documentatie over die projecten relatief diep is en het gebruik het internet heeft verzadigd, hoeven front-end ontwikkelaars niet noodzakelijkerwijs onderhouden Bootstrap, zolang de primaire bron de kernimplementaties van Bootstrap behoudt. Als u echter het Bootstrap-framework eenvoudig opneemt voor het raster of een paar UI-elementen, moet u in plaats daarvan een aangepaste versie bouwen die niet de extra CSS bevat die u nooit van plan bent te gebruiken.
Het is mogelijk dat uw toepassing iets doet dat een groot aantal selectors, kleuren of lettergroottes vereist. Als u bijvoorbeeld een online winkel met productkleuren gebruikt, is het mogelijk dat een groot aantal kleuren in uw CSS wordt weergegeven en een volledig legitiem geval is. Een ander voorbeeld is als u een site gebruikt waarmee gebruikers kunnen kiezen uit een lijst met lettergroottes en lettertypen voor inhoud die ze maken. In deze voorbeelden is het logisch om grote aantallen in die specifieke categorieën te zien.
Medium.com gebruikt ergens een lettergrootte van 301px ... Als u echter iets maakt zoals bijvoorbeeld een blog met een beperkt kleurenschema, moeten uw CSS-statistieken die kleurselectie en het aantal declaratietellers weerspiegelen..
Bepaalt u twintig keer dezelfde lettergrootte in uw CSS? Dit kan vaak worden voorkomen en is meestal het gevolg van een gebrek aan planning. Als u uw lettergroottes bepaalt voordat u een andere CSS schrijft, kunt u die maten eenvoudiger toepassen op de rest van het systeem.
Hetzelfde geldt voor elke herhaalde stijl; als je merkt dat je meerdere keren hetzelfde schrijft, verdient die set stijlen misschien een eigen presentatieve of semantische klasse of andere modulaire definitie?
Ga hier niet overboord; het herdefiniëren van een paar lettergroottes of achtergrondkleuren is geen big deal. Het opnieuw definiëren van een aantal stijlen meerdere keren op zeer vergelijkbare modules kan echter betekenen dat u een basisklasse moet uitbreiden. Als u bijvoorbeeld een knopklasse hebt:
.btn font-size: 1.2em; font-gewicht: 400; letter-spacing: .06em; kleur: #fff; achtergrondkleur: # 4a4a4a; opvulling: 6px 8px;
Stel dat u een blauwe versie van diezelfde knop wilt. Hoe zou je dat moeten definiëren? Als je hetzelfde herdefinieert BTN klasse, het zou er ongeveer zo uitzien:
.btn-blue font-size: 1.2em; font-gewicht: 400; letter-spacing: .06em; kleur: #fff; achtergrondkleur: # 0C508D; opvulling: 6px 8px;
Natuurlijk zijn er veel problemen mee. Ten eerste schendt het het DRY-principe (niet jezelf herhalen). Maar waarom doet dat ertoe? Onderhoudbaarheid. Laten we bijvoorbeeld zeggen dat het ontwerp verandert en vraagt om een kleinere lettertype-aan-knop. Je moet dan in de .BTNen de .btn-blauw klasse om de lettergrootte te wijzigen. Nog meer complicaties doen zich voor als u varianten van de blauwe en normale grijze knoppen nodig heeft, zoals een blauw-omtrekversie. Al uw wijzigingen aan een enkele knop moeten op vele knoppen worden aangebracht.
Dit is ongelooflijk inefficiënt. In plaats daarvan zou u moeten profiteren van het feit dat klassen modulair zijn en u in staat stellen om knopstijlen te definiëren die uw basis uitbreiden .BTN klasse.
.btn font-size: 1.2em; font-gewicht: 400; letter-spacing: .06em; kleur: #fff; achtergrondkleur: # 4a4a4a; opvulling: 6px 8px; .btn.btn-blue background-color: # 0C508D;
Aha! En nu hebben we een veel onderhoudsvriendelijke oplossing, die ook een aanzienlijk aantal CSS-regels verwijdert en het DRY-principe volgt.
Specificiteit is een van de moeilijk te begrijpen donkere hoeken van CSS die zelfs de meest ervaren ontwikkelaars vaak in de war brengt. Op CSS-statistieken kunt u een specificiteitskaart zien die laat zien hoe specifiek de selectors in uw CSS zijn, en ook waar die selectors verschijnen.
CSS-specificiteit van de BBC-websiteDeze grafiek toont de specificiteit van selectors zoals ze worden aangetroffen in de CSS van bbc.co.uk. Stel je voor dat de linkerkant van de grafiek de bovenkant van het stylesheet is, dan beweegt het langs de x-as als het de stylesheet leest. Hoe specifieker de regel, hoe hoger de donkerblauwe lijn op de y-as.
We zullen drie algemene 'vuistregels' geven om mee te beginnen en vervolgens de regels uitleggen.
We zullen hier dieper op ingaan, maar laten we het eerst een beetje bespreken over hoe specificiteit werkt.
Aan CSS-selectors wordt een specificiteitsscore toegekend om de browserweergave-engine te informeren welke regels van toepassing zijn op welke elementen. De reden waarom dit nodig is, is ook de reden waarom CSS zo krachtig is: stijlen kunnen worden overgenomen en gecascadeerd in CSS. Dit betekent dat u meer dan één set stijlen op een bepaald element kunt toepassen. De renderingsengine moet al deze regels consolideren en iets presenteren, maar wat gebeurt er wanneer twee verschillende waarden worden ingesteld voor dezelfde stijlverklaring? Bijvoorbeeld:
een color: #fff; a.button kleur: # 000;
Wanneer de CSS-engine een label met een klasse van knop, het moet bepalen of het kleur attribuut zou moeten zijn #fff, # 000, of de standaardinstelling van de browser. CSS-specificiteit is de regelset die de browser gebruikt om deze beslissing te nemen.
Dus, hoe werkt specificiteit? Gebruik dit scoresysteem als een leidraad, rechtstreeks overgenomen van CSS Tricks:
Accentsconagua
!belangrijk overtreft ze allemaal* selectors krijgen een specificiteitsscore van alle 0s.Merk op dat in dit scoresysteem, wanneer iets meer dan 10 is, het niet in de volgende kolom gaat, dus bijvoorbeeld als je een selector had die 11 elementen lang was, zou het niet overlopen om een specificiteit van 0 te zijn, 0,1,1. Het zou in plaats daarvan 0,0,0,11 zijn.
Hier zijn enkele selectors en hun resulterende scores.
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 * /
een achtergrondkleur: blauw! belangrijk; / * In het vorige voorbeeld hebben we inline stijlen gebruikt om de achtergrondkleur in te stellen op rood. Als we deze stijl echter toepassen met de! Belangrijke kwalificatie, zou dit de inline-stijl overschrijven. * /
Okay - nu dat we een basisprimer uit de weg hebben voor CSS-specificiteit, hoe zou dat onze code moeten beïnvloeden? Laten we teruggaan naar onze drie vuistregels voor CSS-specificiteit.
Deze regel stelt in feite dat algemene selectors aan het begin van uw CSS staan, en dat er later meer specifieke selectors in uw CSS moeten komen. De redenen voor deze regel zijn talrijk.
Ten eerste stelt het plaatsen van algemene regels aan het begin van uw toepassing meestal het stadium in uw code voor basismodules die moeten worden aangemaakt. In combinatie met # 2, zorgt het hebben van de minst specifieke stijlen aan het begin ervoor dat je het eerst met de minste specificiteit schrijft. Later, als uw code evolueert, kan het toevoegen van meer specifieke stijlen noodzakelijk worden om eerdere stijlen te overschrijven of uit te breiden.
Stijlen op de website van Apple zijn vroeg in het stylesheet erg specifiek
De specificiteit van het Pure CSS-framework neemt over het algemeen toe naar het einde van het stylesheetDit leidt tot ons tweede punt: wat gebeurt er wanneer de CSS-rendering-engine twee selectors tegenkomt die dezelfde score hebben? Het moet nog steeds kiezen, dus het zal voor de laatste van de twee regels kiezen. Door zich aan het begin van uw bestand te vergissen tot het minst specifiek, zorgt u ervoor dat uw specificiteitsvervangingen specifieker zijn naarmate u later in het bestand gaat. Dit betekent dat een enkele klasse later in het bestand overwogen moet worden om enkele klassen eerder in het bestand te vervangen.
Deze oefening zorgt ervoor dat latere ontwikkelingen van hetzelfde project snel het cascadesysteem kunnen begrijpen.
Als je al lang een ontwikkelaar van een front-end bent, heb je waarschijnlijk de "CSS specificity war" ervaren. U schrijft een selector en enkele regels en vernieuwt vervolgens de browser om te zien dat de wijzigingen niet zijn toegepast. Je weet uit eerdere projecten of uit gesprekken over specificiteit dat het komt omdat je selector niet specifiek genoeg is, dus in plaats van het probleem terug te traceren naar de selector die te specifiek is, besluit je de nieuwe te maken meer specifiek. Je voegt een ID of twee toe en als dat niet lukt, gooi je gewoon !belangrijk erop. En, voila - je stijlen verschijnen.
Deze aanpak werkt, technisch gesproken; maar helaas, telkens als je die stijl wilt uitbreiden, moet je doorgaan met het vergroten van de complexiteit, en voor je het weet zijn je selectors uiterst specifiek, en je moet code herhalen in plaats van gewoon klassen opnieuw te gebruiken. Bovendien is het bijna onmogelijk om precies te bepalen welk niveau van specificiteit elke nieuwe stijl zou moeten hebben zonder meer en meer ID's toe te voegen en !belangrijk declaraties.
Uw kiezers minder specifiek houden, is een veel veiligere, beter onderhoudbare manier om met uw CSS om te gaan.
Deze regel is er vooral om vreemde regels te voorkomen. Als u bijvoorbeeld enkele klassen voor tekstpresentatie definieert en ineens een regel hebt die zes klassen en een ID nesten, moet die specifieke regel contextueel worden geplaatst met meer specifieke selectors die betrekking hebben op.
CSS-statistieken kunnen u inzicht geven in de manier waarop uw CSS is geschreven, maar dit is alleen nuttig als u een idee hebt van hoe deze statistieken eruit moeten zien voordat u ze probeert te analyseren. Dit betekent dat je een diep contextueel begrip hebt van de manier waarop je CSS is geschreven en waarom. Als uw CSS onderhoudbaar en geschikt is voor de site waarop deze wordt gebruikt, zijn de statistieken van die CSS niet voldoende reden om uw code te refactoren.
In plaats van blindelings de nummerregels te volgen, moet je je als een verantwoordelijke front-end ontwikkelaar richten op het onderhoudbaar maken van je code en het verminderen van de zwelling. Statistieken over uw code helpen u wellicht probleemgebieden te vinden, maar ze kunnen alleen zo ver gaan.
