Administrer store CSS-projekter med ITCSS

Harry Roberts taler kl Generer Bangalore den 2. december. Gå ikke glip af hans tale refactoring af CSS uden at miste tankerne , hvor han deler sine tip og teknikker til at håndtere ældre CSS. Book nu at blive et stiftende medlem af Generate og få 50% rabat på alle fremtidige Generate-konferencer over hele verden!



CSS-arkitektur ser ud til at være noget på mode lige nu. Det er noget, du uden tvivl har hørt nævnt adskillige gange i løbet af det sidste år eller deromkring, og med god grund: UI'er (og de hold, der bygger dem) bliver større og mere komplicerede end nogensinde før.



Der er en række aspekter af CSS, der gør det besværligt. Det er deklarativt, hvilket betyder, at der ikke er nogen logik eller kontrolflow, der fortæller andre udviklere meget om tilstanden eller opbygningen af ​​projektet. Det fungerer i et globalt navneområde, hvilket betyder, at vi får kollisioner, utætte stilarter og utilsigtede regressioner. Det bruger arv, hvilket gør alt noget indbyrdes afhængigt og skørt. Endelig kan den uundgåelige specificitetsmodel skabe problemer, når vælgerne kæmper med hinanden for fremtrædende plads.

Dette er alle problemer i sig selv, men når man arbejder i en hvilken som helst rimelig skala, bliver de enten direkte mere tydelige, eller oddsene for at støde på sådanne problemer er statistisk meget højere. Indtast en CSS-arkitektur: en måde at planlægge og strukturere din CSS på store og langvarige projekter.



Introduktion til ITCSS

Arkitekturen, vi skal se på i dag, hedder ITCSS - 'Inverted Triangle CSS'. Dette er en metode, der involverer at visualisere hele dit CSS-projekt som en lagdelt, på hovedet trekant. Denne hierarkiske form repræsenterer en model, der hjælper dig med at bestille din CSS på den mest effektive, mindst spildte måde. Lad os grave ind!

ITCSS er noget, jeg har arbejdet med i en eller anden form i omkring fire år nu. Det er ikke tilfældigt, at jeg også har brugt de sidste fire år udelukkende på digitale produkter: store, langvarige projekter med hele hold af ingeniører, der arbejder på den samme kodebase i flere måneder i træk.

Det er i denne form for miljø (arv, nye funktioner, mange bidragydere, høj hastighed, påløbet tech-gæld, modstridende interessenters bekymringer), at der kræves meget mere omhu og struktur med den kode, vi skriver. Dette er grunden til, at jeg opfandt ITCSS; for at hjælpe udviklere, der arbejder på disse store projekter med bedre organisering, skalering og styring af deres CSS.



Hvad ITCSS sigter mod at gøre er at give et niveau af formalitet og struktur til den måde, vi skriver vores CSS på. Det er ikke en enorm afvigelse fra normen, hvilket betyder, at overgangen til ITCSS ikke bør vise sig at være for vanskelig. Desuden, hvor de fleste arkitekturer og tilgange forsøger at undgå CSS's irriterende aspekter, omfavner og tæmmer ITCSS dem og får dem til at fungere til vores fordel. ITCSS definerer de delte aspekter af et projekt på en logisk og fornuftig måde, samtidig med at det giver et solidt niveau af indkapsling og afkobling, der beskytter de ikke-delte aspekter fra at forstyrre hinanden.

ITCSS er også utrolig fleksibel. Det er kompatibelt med aspekter af andre metoder som SMACSS, OOCSS og endda BEM. Det kan forlænges eller parres tilbage efter behov afhængigt af dit projekt. Det fungerer med eller uden en forprocessor, og det håndhæver ikke nogen specifikke navngivningskonventioner (selvom jeg altid vil anbefale, at du bruger en). Denne fleksibilitet betyder, at ITCSS kan bruges i enhver projektstørrelse eller stil.

hvordan man laver gitter i indesign

Forudsætninger

Før vi dykker ind i detaljerne, er der nogle få forudsætninger, når vi arbejder med ITCSS. Alle disse bliver standardpraksis for enhver moderne UI-udvikler. For det første ingen id'er i CSS. ID'er er tungvægte af specificitet, og deres anvendelse vil kaste vores specificitet helt ud af leddet.

For det andet skal du arbejde med en komponentiseret UI-arkitektur. Du bygger ikke længere til 'sider'-modellen, men til widgets / moduler / komponenter mønster (ITCSS henviser til disse som' komponenter '). Du bygger diskrete, selvstændige stykker UI som genanvendelige komponenter.

Endelig kræver ITCSS, at du er for en klassebaseret arkitektur. Du er ikke bange for at tilføje klasser til din HTML; du tror ikke på, at 'mindre markering' og 'ren markering' er den samme ting; og du forstår, at binding til klasser snarere end bare HTML-elementer giver en mere robust og skalerbar arkitektur.

Lær, hvordan du refaktorerer CSS uden at miste tankerne på Generate Bangalore

Lær, hvordan du refaktorerer CSS uden at miste tankerne på Generate Bangalore

Vigtige målinger

ITCSS er en fuldt administreret arkitektur, hvilket betyder, at den fortæller dig, hvordan du konstruerer hele dit CSS-projekt. Det fortæller dig ikke bare, hvordan du f.eks. Bygger dine komponenter, men hjælper dig med at styre alt fra Sass-arkitektur til kildearrangement, typografiske typografier på lavt niveau til tema og meget mere.

ITCSS fungerer ved at bestille hele dit CSS-projekt efter tre nøglemålinger. Vi ser på disse nu.

Usædvanlig eller uovervejet kildeordre kan føre til en uregelmæssig og sprød anvendelse af stilarter

Usædvanlig eller uovervejet kildeordre kan føre til en uregelmæssig og sprød anvendelse af stilarter

01. Generisk til eksplicit

Vi starter med de mest generiske, low-level, catch-all, ikke-bemærkelsesværdige stilarter, og til sidst udvikler vi os til mere eksplicitte og specifikke regler, når vi bevæger os gennem projektet. Vi starter muligvis med vores nulstilling og går derefter videre til lidt mere omfangsrige regler som h1–6 {}, helt igennem til ekstremt eksplicitte regler såsom .text-center {}.

02. Lav specificitet til høj specificitet

Vælgerne med den laveste specificitet vises mod begyndelsen, med specificitet, der stiger støt, når vi går igennem projektet. Vi vil sikre, at vi undgår så meget af specificitetskrigene, som vi kan, så vi prøver at afstå fra at skrive vælgere med højere specificitet før dem med lavere specificitet. Vi tilføjer altid specificitet i samme retning og undgår dermed konflikter.

03. Vidtrækkende til lokaliseret

Vælgerne i starten af ​​projektet påvirker meget af DOM, hvor rækkevidden gradvist mindskes, når vi går gennem kodebasen. Vi ønsker at 'passere' over DOM ved at skrive regler, der gradvis påvirker mindre og mindre af det.

Vi starter muligvis med at tørre margenerne og polstringerne af alt, så kan vi style hver type element og derefter indsnævre det til hver type element med en bestemt klasse anvendt på det osv. Det er denne gradvise indsnævring af rækkevidde, der giver os trekantsformen.

billige macbook pro-sager 13 tommer

Bestilling af vores projekter i henhold til disse nøgletal har flere fordele. Vi kan begynde at dele globale og vidtrækkende stilarter meget mere effektivt og effektivt, vi reducerer sandsynligheden for specificitetsproblemer betydeligt, og vi skriver CSS i en logisk og progressiv rækkefølge. Dette betyder større udvidelighed og mindre redundans, hvilket igen betyder mindre spild og meget mindre filstørrelser.

Lag

Den omvendte trekant tre vigtige metrics

Den omvendte trekant tre vigtige metrics

Vi kan holde os til disse målinger ved at bryde vores CSS op i flere sektioner eller 'lag'. Hvert lag skal introduceres på et sted, der overholder hvert af kriterierne. De fleste mennesker (og arkitekturer) forsøger at opdele CSS-projekter op i tematiske grupper: her er vores typografiske stilarter, her er vores formstilarter, her er vores billedgalleristile. Ulempen ved dette er, at det ikke er særlig sympatisk for, hvordan CSS rent faktisk fungerer, og ikke bestiller CSS på en måde, der bedst udnytter, tæmmer eller drager fordel af kaskaden, arv eller specificitet.

I ITCSS er hvert lag en logisk progression fra det sidste. Det øges i specificitet, det bliver mere eksplicit og tilsigtet, og det indsnævrer rækkevidden for de valgte vælgere. Det betyder, at vores CSS i sagens natur er lettere at skalere, da vi skriver det i en rækkefølge, der kun nogensinde føjer til det, der blev skrevet tidligere. Vi spilder ikke tid på at fortryde eller tilsidesætte alt for meningsfuld CSS, der blev skrevet tidligere.

Det betyder også, at enhver ting og enhver type ting har sit eget konsistente, forudsigelige sted at bo. Dette gør både at finde og tilføje stilarter meget enklere, hvilket er især nyttigt, når du har et antal udviklere, der bidrager til kodebasen.

ITCSS har som standard syv lag. Vi ser på hver af disse efter tur nu.

01. Indstillinger

Hvis du bruger en forprocessor, skal du starte her. Dette indeholder eventuelle globale indstillinger for dit projekt. Jeg vil gerne understrege ordet globalt - dette lag skal kun indeholde indstillinger, der skal tilgås overalt. Indstillinger som $ heading-size-1 skal defineres i overskriften delvis. Dette sikrer, at dette lag forbliver pænt og slankt, og betyder at de fleste indstillinger kan findes sammen med den kode, der bruger dem, hvilket gør det meget enklere at finde ting.

Eksempler på globale indstillinger kan være ting som basis skriftstørrelse, farvepaletter, konfiguration (for eksempel $ miljø: dev;) og så videre.

02. Værktøjer

Det næste lag huser dit globalt tilgængelige værktøj - nemlig mixins og funktioner. Enhver mixin eller funktion, der ikke har brug for adgang globalt, skal høre til den del, som den vedrører. Værktøjslaget kommer efter indstillingslaget, fordi et mixin muligvis kræver en af ​​de globale indstillinger som standardparameter. Eksempler på globale værktøjer kan være gradient mixins, font-dimensionering mixins og så videre.

03. Generisk

Det generiske lag er det første, der faktisk producerer en CSS. Det huser meget højt niveau, vidtgående stilarter. Dette lag ændres sjældent og er normalt det samme på tværs af alle projekter, du arbejder på. Den indeholder ting som Normalize.css, globale boksstørrelsesregler, CSS-nulstillinger og så videre. Det generiske lag påvirker meget af DOM, hvorfor det er pænt og bredt i trekantmodellen og forekommer meget tidligt.

04. Elementer

Disse er bare, ikke-klassificerede HTML-elementer. Hvordan ser en h1 ud uden en klasse på den? Hvordan ser et ud uden en klasse på det? Elementelaget binder kun til bare HTML-element (eller 'type') vælgere. Det er lidt mere eksplicit end det forrige lag, idet vi nu siger 'gør hver h1 så stor' eller 'gør hver en til en bestemt farve'. Det er stadig et lag med meget lav specificitet, men påvirker lidt mindre af DOM og er lidt mere meningsfuldt, derfor dets placering i trekanten.

Elementelaget er typisk det sidste, hvor vi finder nøgne, elementbaserede vælgere, og føjes meget sjældent til eller ændres efter den første opsætning. Når vi har defineret typografier på elementniveau, skal alle tilføjelser og afvigelser implementeres ved hjælp af klasser.

05. Objekter

Brugere af OOCSS vil være fortrolige med begrebet objekter. Dette er det første lag, hvor vi finder klassebaserede vælgere. Disse vedrører styling af ikke-kosmetiske designmønstre eller 'genstande'. Objekter kan variere fra noget så simpelt som et .wrapper-element til layoutsystemer til ting som OOCSS-plakatbarnet - Media Object. Dette lag påvirker mindre af DOM end det sidste lag, har en højere specificitet og er lidt mere eksplicit, fordi vi nu målretter mod sektioner af DOM med klasser.

06. Komponenter

Komponentlaget er, hvor vi begynder at style genkendelige stykker UI. Vi binder stadig til klasser her, så vores specificitet er endnu ikke steget. Dette lag er dog mere eksplicit end det sidste, idet vi nu styler eksplicitte, designede stykker af DOM.

Vi bør ikke finde nogen vælgere med en lavere specificitet end en klasse i dette lag. Det er her størstedelen af ​​dit arbejde vil ske efter den første projektopsætning. Tilføjelse af nye komponenter og funktioner udgør normalt langt størstedelen af ​​udviklingen.

07. Trumps

Dette lag slår - eller 'trumfer' - alle andre lag og har magten til at tilsidesætte alt, hvad der er gået før det. Det er uelegant og tunghændet og indeholder nytte- og hjælperklasser, hacks og tilsidesættelser.

Mange af erklæringerne i dette lag vil have! Vigtig (f.eks.. Tekst-center {text-align: center! Vigtigt;}). Dette er det højeste specificitetslag - det inkluderer de mest eksplicitte typer af regler med det mest snævre fokus. Dette lag danner punktet i trekanten.

Efter denne lagdelte, nøgle metrics-baserede ITCSS-kildearrangemetode giver os en fornuftig anvendelse af stilarter i hele vores projekt

Efter denne lagdelte, nøgle metrics-baserede ITCSS-kildearrangemetode giver os en fornuftig anvendelse af stilarter i hele vores projekt

Så i stedet for at gruppere ting i 'typografiske stilarter' eller 'formstilarter' deler vi dem i grupper baseret på specificitet, rækkevidde og eksplicitet. Dette format giver os mulighed for at skrive vores CSS i en rækkefølge, der kun nogensinde føjer til og arver fra det, der kom tidligere.

Vi bruger meget lidt tid på at fortryde ting, for vores kaskade og specificitet peger alle i samme retning. Vi reducerer antallet af kollisioner, lækager og omdefineringer drastisk.

Hvis vi forestiller os trekanten igen som en kegle, kan vi se ned i den for at se hvert lags rækkevidde

Hvis vi forestiller os trekanten igen som en kegle, kan vi se ned i den for at se hvert lags rækkevidde

Delvis

Hvert lag indeholder en række deldele. Jeg anbefaler navngivningskonventionen _ .. scss (for eksempel: _settings.colors.scss, _elements.headings.scss, _components.tabs.scss).

Disse partialer skal holdes så små og granulære som muligt, hvor hver kun indeholder så meget CSS, som det er nødvendigt for at udføre sin rolle. Så _elements.headings.scss ville kun indeholde reglerne h1 til h6 og intet mere. Hvis du for eksempel har en sidetitelkomponent, der får en hovedoverskrift (f.eks. H1) og en underoverskrift (f.eks. H2) til at se en bestemt måde ud, opretter du en _components.page-title.scss delvis i komponentlaget og binder på klasser (f.eks. side-titel, .side-titel-sub), ikke på HTML-elementer.

hvordan man tegner en menneskelig torso

Sådan fungerer ITCSS: vi placerer ikke alle vores kursrelaterede stilarter sammen. I stedet placerer vi alle vores elementbaserede regler sammen og alle vores klassebaserede regler sammen. Vi bestiller nu projektet baseret på nyttige CSS-målinger og skaber ikke akavet specificitet og kaskadegrupper ved at bestille projektet i tematiske klumper.

Resultatet

Når alt dette kommer sammen, kan det se sådan ud:

@import 'settings.global'; @import 'settings.colors'; @import 'tools.functions'; @import 'tools.mixins'; @import 'generic.box-sizing'; @import 'generic.normalize'; @import 'elements.headings'; @import 'elements.links'; @import 'objects.wrappers'; @import 'objects.grid'; @import 'components.site-nav'; @import 'components.buttons'; @import 'components.carousel'; @import 'trumps.clearfix'; @import 'trumps.utilities'; @import 'trumps.ie8';

Selv i dette lille eksempel kan du se, hvordan hvert lag kan indeholde et vilkårligt antal partialer, og disse partialer kan teoretisk sidde i enhver @import-rækkefølge, du ønsker. Det eneste krav er, at lagene selv altid forbliver i denne formation.

Vi sikrer, at hvert lag indeholder CSS af:

  • En lignende specificitet: Alle elementbaserede vælgere eller alle klassebaserede vælgere eller hjælpeklasser, der bærer! Vigtigt
  • En lignende eksplicititet: Styling af alle dine bare HTML-elementer eller styling af UI-komponenter eller styling af specifikke hjælperklasser
  • En lignende rækkevidde: Evne til at påvirke hele DOM (f.eks. * {}), En delmængde af DOM (f.eks. En {}), en sektion af DOM (f.eks. Karrusel {}) eller en bestemt DOM-knude (f.eks. clearfix {})

Denne drill-down tilgang giver os en meget mere håndterbar CSS-arkitektur. Nu ved vi, at alt, hvad vi tilføjer, skal være en tilføjelse til det, der er gået før det. Vi ved, hvor hver type regel vil bo, og hvor de nye stilarter skal placeres, og vi har tillid til, at alle vores forskellige vælgere vil spille pænt sammen med hinanden.

Hvis du vil udforske ITCSS yderligere, skal du kigge på Harry Roberts 'indledende samtale på DaFED ...

Hader at arbejde med ældre CSS? Gå ikke glip af Harry Roberts ' Generer Bangalore tale videre refactoring af CSS uden at miste tankerne . Book nu at nyde denne og andre samtaler fra førende webnavne, herunder Jonathan Snook, Stephanie Rieger og Shikhar Kapoor.

Denne artikel opstod oprindeligt i nummer 267 af netmagasin .