CSS-navngivningskonventioner, der sparer timevis af fejlretning

Jeg har hørt mange udviklere sige, at de hader CSS. Efter min erfaring kommer dette som et resultat af ikke at tage tid til at lære CSS.

Koreansk ??

알림: 한국인 독자 분들 을 위해 본 기사 는 한국어 로 번역 한국어, 한국어 버전 은 여기 에서 보실 수 있습니다

CSS er ikke det smukkeste 'sprog', men det har med succes drevet stylingen af ​​internettet i over 20 år nu. Går det ikke for dårligt, ikke?

Når du skriver mere CSS, ser du dog hurtigt en stor ulempe.

Det er svært at vedligeholde CSS.

Dårligt skrevet CSS bliver hurtigt et mareridt.

Her er et par navngivningskonventioner, der sparer dig lidt stress og utallige timer ned ad linjen.

Brug bindestreg afgrænsede strenge

Hvis du skriver meget JavaScript, er det almindelig praksis at skrive variabler i kamel tilfælde.

var redBox = document.getElementById('...')

Fantastisk, ikke?

Problemet er, at denne form for navngivning ikke er velegnet til CSS.

Gør det ikke:

.redBox { border: 1px solid red;}

I stedet skal du gøre dette:

.red-box { border: 1px solid red;}

Dette er en ret standard CSS-navngivningskonvention. Det er uden tvivl mere læsbart.

Det er også i overensstemmelse med CSS-ejendomsnavne.

// Correct
.some-class { font-weight: 10em}
// Wrong
.some-class { fontWeight: 10em}

BEM-navngivningskonventionen

Hold har forskellige tilgange til at skrive CSS-vælgere. Nogle hold bruger bindestregafgrænsere, mens andre foretrækker at bruge den mere strukturerede navngivningskonvention kaldet BEM.

Generelt er der 3 problemer, som CSS-navngivningskonventioner forsøger at løse:

  1. At vide, hvad en vælger gør, bare ved at se på dens navn
  2. At have en idé om, hvor en vælger kan bruges, bare ved at se på den
  3. At kende forholdet mellem klassenavne ved bare at se på dem

Har du nogensinde set holdnavne skrevet sådan:

.nav--secondary { ...}
.nav__header { ...}

Det er BEM-navngivningskonventionen.

Forklaring af BEM til en 5-årig

BEM forsøger at opdele den samlede brugergrænseflade i små genanvendelige komponenter.

Overvej billedet nedenfor:

Nej, det er ikke prisvindende :(

Stick-man repræsenterer en komponent, såsom en blok af design.

Du har måske allerede gættet, at B i BEM står for 'Block'.

I den virkelige verden kan denne 'blok' repræsentere en webstedsnavigation, sidehoved, sidefod eller enhver anden blok af design.

Efter den ovenfor forklarede praksis ville et ideelt klassenavn for denne komponent være stick-man.

Komponenten skal designes således:

.stick-man { }

Vi har brugt afgrænsede strenge her. Godt!

E for Elements

E i 'BEM' står for Elements.

Overordnede designblokke lever sjældent isoleret.

For eksempel har stick-man en head, to smukke arms, og feet.

De head, feetog armser alle elementer i komponenten. De kan ses som underordnede komponenter, dvs. børn af den overordnede forældrekomponent.

Ved hjælp af BEM-navngivningskonventionen afledes elementklassenavne ved at tilføje to understregninger efterfulgt af elementnavnet.

For eksempel:

.stick-man__head {
}
.stick-man__arms {
}
.stick-man__feet {
}

M til modifikatorer

M i 'BEM' står for modifikatorer.

Hvad hvis stick-manen blev modificeret, og vi kunne have en blueeller en redstick-man?

I den virkelige verden kan dette være en redknap eller blueknap. Dette er ændringer af den pågældende komponent.

Ved hjælp af BEM stammer modifikatorklassens navne ved at tilføje to bindestreger efterfulgt af elementnavnet.

For eksempel:

.stick-man--blue {
}
.stick-man--red {
}

Det sidste eksempel viste, at den overordnede komponent blev ændret. Dette er ikke altid tilfældet.

Hvad hvis vi havde stick-mænd i forskellige headstørrelser?

Denne gang er elementet blevet ændret. Husk, at elementet er en underordnet komponent i den samlede indholdsblok.

Den .stick-manrepræsenterer Block, .stick-man__headelementet.

Som det ses i eksemplet ovenfor, kan dobbeltstreg også bruges som sådan:

.stick-man__head--small {
}
.stick-man__head--big {
}

Igen bemærk brugen af ​​de dobbelte bindestreger i eksemplet ovenfor. Dette bruges til at betegne en modifikator.

Nu har du det.

Sådan fungerer BEM-navngivningskonventionen.

Personligt har jeg en tendens til kun at bruge bindestregafgrænser klassenavne til enkle projekter og BEM til mere involverede brugergrænseflader.

Du kan læse mere om BEM.

BEM - Block Element Modifier

BEM - Block Element Modifier er en metode, der hjælper dig med at opnå genanvendelige komponenter og kodedeling i ... getbem.com

Hvorfor bruge navngivningskonventioner?

Der er kun to hårde problemer i datalogi: ugyldiggørelse af cache og navngivning af ting - Phil Karlton

At navngive ting er svært. Vi prøver at gøre tingene lettere og spare os tid i fremtiden med mere vedligeholdelig kode.

At navngive ting korrekt i CSS vil gøre din kode lettere at læse og vedligeholde.

Hvis du vælger at bruge BEM-navngivningskonventionen, bliver det lettere at se forholdet mellem dine designkomponenter / blokke bare ved at se på markeringen.

Følelse af selvtillid?

CSS-navne med JavaScript-kroge

I dag er Johns første arbejdsdag.

Han får udleveret en HTMLkode, der ser sådan ud:

John har læst denne artikel og indser, at det måske ikke er den bedste måde at navngive ting på CSS. Så han fortsætter og refaktorer kodebasen som sådan:

Ser godt ud, ikke?

Ukendt for John, han havde brudt kodebasen ???

Hvordan?

Et eller andet sted i JavaScript-koden var der et forhold til det forrige klassens navn siteNavigation:

//the Javasript code
const nav = document.querySelector('.siteNavigation')

Så med ændringen i klassens navn blev navvariablen null.

Hvor trist.

For at forhindre sager som dette har udviklere kommet med forskellige strategier.

1. Brug js- klasse navne

En måde at afbøde sådanne fejl på er at bruge en js-*klasse navn for at betegne et forhold til det pågældende DOM-element.

For eksempel:

Og i JavaScript-koden:

//the Javasript code
const nav = document.querySelector('.js-site-navigation')

Som en konvention vil enhver, der ser js-site-navigationklassens navn, forstå, at der er et forhold til det DOM-element i JavaScript-koden.

2. Brug Rel-attributten

Jeg bruger ikke denne teknik selv, men jeg har set folk gøre.

Kan du genkende dette?

Grundlæggende definerer rel-attributten det forhold, som den sammenkædede ressource har til det dokument, som det henvises til.

I det foregående eksempel med John ville tilhængere af denne teknik gøre dette:

Og i JavaScript:

const nav = document.querySelector("[rel='js-site-navigation']")

Jeg er i tvivl om denne teknik, men du vil sandsynligvis komme over det i nogle kodebaser. Påstanden her er, ”ja, der er et forhold til Javascript, så jeg bruger rel-attributten til at betegne det” .

Internettet er et stort sted med mange forskellige “metoder” til løsning af det samme problem.

3. Brug ikke dataattributter

Nogle udviklere bruger dataattributter som JavaScript-kroge. Dette er ikke rigtigt. Per definition bruges dataattributter til at gemme brugerdefinerede data .

Rediger nr. 1: Som nævnt af nogle fantastiske mennesker i kommentarsektionen, hvis folk bruger attributten 'rel', er det måske okay at bruge dataattributter i visse tilfælde. Det er dit opkald efter alt.

Bonustip: Skriv flere CSS-kommentarer

Dette har intet at gøre med navngivningskonventioner, men det sparer dig også lidt tid.

Mens mange webudviklere prøver at IKKE skrive JavaScript-kommentarer eller holde sig til et par, synes jeg du skal skrive flere CSS-kommentarer.

Da CSS ikke er det mest elegante "sprog", kan velstrukturerede kommentarer spare tid, når du prøver at forstå din kode.

Det gør ikke ondt.

Se på, hvor godt kommenteret Bootstrap-kildekoden er.

Du behøver ikke at skrive kommentarer for at sige, at de color: redvil give en rød farve. Men hvis du bruger et CSS-trick, der er mindre indlysende, er du velkommen til at skrive en kommentar.

Klar til at blive Pro?

Jeg har oprettet en gratis CSS-guide for straks at få dine CSS-færdigheder flammende. Få den gratis e-bog.