Udjævning i CSS

CSS virker let i starten. Det er jo bare styling, ikke?

Men giv det tid. Snart viser CSS dig de sande dybder af dens kompleksitet.

Der er fire ting, du kan gøre for at forblive fornuftig, mens du bruger CSS i skala: brug ordentlig semantik, modularisere, vedtage en navnekonvention og følge princippet om enkeltansvar.

Brug korrekt semantik

I HTML og CSS er der begrebet semantisk markup. Semantik er betydningen af ​​ord og deres forhold. I forbindelse med HTML betyder det at bruge passende markup tags. Her er et klassisk eksempel.



Semantisk HTML er temmelig ligetil. På den anden side er semantisk CSS meget mere abstrakt og subjektiv. At skrive semantisk CSS betyder at vælge klassenavne, der formidler strukturel betydning og funktion. Kom med klassens navne, der er lette at forstå. Sørg for, at de ikke er for specifikke. På den måde kan du genbruge dine klasser.

For at illustrere gode semantiske klassenavne er her et forenklet eksempel på Medium's CSS.

  
    
      
                       

Fra koden kan du straks skelne mellem struktur, rolle og mening. Forældreklassen er stream, en liste med artikler. Børneklassen er streamItem, en faktisk artikel på listen. Det er klart, hvordan forælder og barn forholder sig til hinanden. Desuden bruges disse klasser på hver side, der indeholder artikler.

Du skal være i stand til at læse HTML og CSS som en bog. Det skulle fortælle en historie. En historie har karakterer og forhold mellem dem. Mere semantisk CSS vil i sidste ende gøre din kode mere vedligeholdelig.

For yderligere læsning skal du tjekke Hvad der gør for semantiske klassenavne, navngive CSS-ting er virkelig hårdt og semantik og følsomhed. Se Om HTML-semantik og frontend-arkitektur for en længere læsning.

modularize

I en periode med komponentbaserede biblioteker som React er modularisering konge. Tænk på komponenter som komposible moduler oprettet ved at dekonstruere grænseflader. Nedenfor er produktjagtens forside-stream. Lad os bryde strømmen ned i forskellige komponenter som en øvelse.

Hver farvet kontur repræsenterer en komponent. Strømmen har mange strømelementer.

  
       

De fleste komponenter kan opdeles i endnu mindre komponenter.

Hver stream-vare har et miniaturebillede og oplysninger om et fremhævet produkt.


  
    
    
             
                    
  

Da strømkomponenten er uafhængig af dens børn, og vice versa, kan du nemt justere eller skifte postklasse uden at foretage væsentlige ændringer i strømklassen.

At tænke på komponenter vil hjælpe dig med at oprette din afkoblings kode. Jo mere afkoblet din kode er, jo lavere er den gensidige afhængighed mellem dine klasser. Dette gør din kode lettere at ændre og arbejde med i det lange løb.

Komponentdrevet design

Når du modulerer din CSS, skal du starte med at opdele dit design i en komponent. Du kan gøre dette med papir og blyant eller i et program som Illustrator eller Sketch. Identificering af komponenter giver dig en idé om, hvordan du navngiver dine klasser, og hvordan de forholder sig til hinanden.

Hvis du vil læse mere om komponentdrevet CSS, skal du tjekke CSS-arkitekturer: skalerbare og modulære fremgangsmåder, skrive modulær CSS med Sass og modularisere din front-end-kode til langvarig vedligeholdelsesevne og sundhed.

Vælg en god navnekonvention

Der er snesevis af CSS-navnekonventioner derude. Nogle mennesker sværger ved deres valg af konvention og hævder, at deres er bedre end andre. I sandhed er den bedste navnekonvention forskellige for hver person. Det bedste råd, jeg nogensinde har modtaget om dette, er: vælg den navnekonvention, der giver dig mest mening.

Her er en kort liste over nogle af navnekonventionerne, folk bruger:

  • Objektorienteret CSS OOCSS
  • Block element modifier (BEM)
  • Skalerbar og modulær arkitektur til CSS (SMACSS)
  • Atomar

Et af mine yndlings navnekonventioner er BEM. BEM står for blok, element og modifikator. Yandex, det russiske ækvivalent med Google, kom med det til problemer, de havde med deres CSS-kodebase i skala.

BEM er en af ​​de enkleste - men alligevel strengeste - af navnekonventionerne.

.blokér {}
.block__element {}
.block - modifikator {}

Blokke repræsenterer klasser på højere niveau. Elementer er børn af blokke. Og modifikatorer repræsenterer forskellige stater.

I eksemplet ovenfor er klassesøgningen blokken, og søgeknappen er dens element. Hvis vi vil ændre tastens tilstand, kan vi tilføje en modifikator som aktiv.

Én ting at huske ved navngivningskonventioner er, at uanset hvilken CSS-navnekonvention du foretrækker, vil du ofte arve eller arbejde på kodebaser med forskellige standarder. Vær åben for at lære nye standarder og alternative måder at tænke på CSS på.

Du kan læse mere om BEM i Sådan får du hovedet rundt på BEM-syntaks, BEM 101 og Intro til BEM. For generel læsning om forskellige konventioner, se OOCSS, ACSS, BEM, SMACSS: hvad er de? Hvad skal jeg bruge?

Følg princippet om enkeltansvar

De enkelte ansvarsprincipper angiver, at hvert modul eller klasse skal have ansvar over en enkelt del af funktionaliteten, der leveres af softwaren, og at ansvaret skal være fuldt indkapslet af klassen.

Inden for rammerne af CSS betyder de enkelte ansvarsprincipper, at kodestykker, klasser og moduler kun skal gøre en ting. Når det anvendes til CSS-filorganisation, betyder det, at selvstændige komponenter som karrusler og navigationsbjælker skal have deres egen CSS-fil.

/ komponenter
  | - karrusel
  | - | - karrusel.css
  | - | - karrusel.partial.html
  | - | - carousel.js
  | - nav
  | - | - nav.css
  | - | - nav.partial.html
  | - | - nav.js

Et andet almindeligt mønster i filorganisation er at gruppere filer efter funktionalitet. For eksempel er i kodestykket ovenfor alle filer, der er relateret til karruselkomponenten, samlet. Ved at anvende denne tilgang gør det meget lettere at finde filer.

Ud over at adskille komponentstilarter er det godt at adskille global stil ved hjælp af princippet om et enkelt ansvar.

/ base
  | - ansøgning.css
  | - typografi.css
  | - farver.css
  | - grid.css

I eksemplet er hver stilproblem opdelt i sin egen fil. På denne måde, hvis du vil opdatere dine farver, ved du nøjagtigt, hvor du skal se.

Uanset hvilken filorganisationskonvention du bruger, lad det enkeltansvarlige princip hjælpe med at guide dine beslutninger. Hvis en fil begynder at blive oppustet, skal du overveje at opdele den på baggrund af, hvad der giver logisk mening.

For mere information om filstrukturer og CSS-arkitektur skal du læse Aesthetic Sass 1: Arkitektur og stilorganisation og skalerbar og vedligeholdelig CSS-arkitektur.

Når princippet om et enkelt ansvar anvendes til individuelle CSS-klasser, betyder det, at hver klasse kun skal have en funktion. Med andre ord, opdel stilarter i forskellige klasser baseret på bekymringer. Her er et klassisk eksempel:

.splash {
  baggrund: # f2f2f2;
  farve: #fffff;
  margin: 20px;
  polstring: 30px;
  grænseradius: 4px;
  position: absolut;
  top: 0;
  højre: 0;
  bund: 0;
  venstre: 0;
}

I eksemplet ovenfor blander vi bekymringer. Splash-klassen indeholder ikke kun præsentations- og stylinglogik for sig selv, men også for dens børn. For at afhjælpe dette kan vi opdele koden i to separate klasser.

.splash {
  position: absolut;
  top: 0;
  højre: 0;
  bund: 0;
  venstre: 0;
}
.splash__content {
  baggrund: # f2f2f2;
  farve: #fffff;
  polstring: 30px;
  grænseradius: 4px;
}

Nu har vi en splash og splash indhold. Vi kan bruge splash som en generisk fuldblodsklasse, der tager ethvert barn. Alle barnets bekymringer, i dette tilfælde splashindholdet, er frakoblet fra forælderen.

Du kan læse mere om anvendelse af den enkelte ansvars tilgang til styling og klasser i Det princip om enkeltansvar, der anvendes til CSS og Enkeltansvar.

Enkelhed over kompleksitet

Spørg enhver god front-end-udvikler eller CSS-arkitekt, og de vil fortælle dig, at de aldrig har været helt tilfredse med deres kode. At skrive god CSS er en iterativ proces. Start enkelt, følg grundlæggende CSS-konventioner og stilguider, og iterere derfra.

Jeg vil meget gerne vide, hvordan du nærmer dig CSS. Hvad er din yndlings navnekonvention? Hvordan organiserer du din kode? Du er velkommen til at efterlade en note eller Tweet til mig.

P. S. Hvis du kunne lide denne artikel, ville det betyde meget, hvis du trykker på anbefalingsknappen eller deler med venner.

Hvis du vil have mere, kan du følge mig på Twitter, hvor jeg poster ikke-sensiske ramblings om design, front-end-udvikling, bots og maskinlæring.