Scrierea unui CSS bun

Publicat: 2016-10-17

Încerc mereu să învăț lucruri noi. Cu toate acestea, încerc și să învăț modalități de a îmbunătăți modul în care fac deja lucrurile. Atât la concertul meu cu normă întreagă, cât și pentru proiectele legate de clienți, lucrul pe care mi-am dorit întotdeauna să-l îmbunătățesc a fost CSS-ul meu. Întotdeauna am simțit că sunt destul de bun când vine vorba de CSS, dar mi s-a părut întotdeauna dezordonat de citit și adesea greu de întreținut.

Ceea ce am încercat să fac, este să aflu ce face CSS bun, lizibil și întreținut. Cred că am venit cu (și am găsit) câteva modalități de a face totul posibil.

Problemele

Sunt câteva lucruri care mă deranjează despre CSS. Cele mai frecvente supărări pe care le am sunt:

  • repetarea codului comun
  • prefixele browserului
  • lipsa de comentarii
  • peste selectori calificati
  • nume de clase sărace

Când vine vorba de proiectele mele personale, îmi asum întreaga responsabilitate pentru codul meu. Rareori îmi comentez CSS-ul și adesea îl tratez ca pe o idee ulterioară. Este pur și simplu greșit.

Multă vreme m-am gândit că numele claselor mele sunt „semantice” și doar eu fac lucruri, așa că nu este nevoie să explic codul, sau mici „hack-uri” sau altceva.

Revenirea la cod într-un proiect de lungă durată demonstrează rapid că această teorie este foarte greșită.

Când vine vorba de cod la locul de muncă, nu-mi asum toată vina. De fapt, o parte a problemei este numărul de oameni care au avut mâna acolo. În prezent, echipa noastră are șapte dintre noi care la un moment dat am scris CSS pentru site-urile noastre, cu alți 6-8 care au venit și au trecut peste ani. Fiecare membru al echipei are diferite niveluri de cunoștințe și abilități în ceea ce privește CSS.

De asemenea, așa cum se întâmplă adesea cu proiectele de lungă durată, o parte din cod este vechi . O mare parte este pre-CSS3, sau pre-orice-trend-era-cool-acum-5 ani. În ambele cazuri, au existat adesea moduri diferite de a face lucrurile în momentul în care a fost scris și, în unele cazuri, o lipsă naturală de cunoștințe.

De asemenea, am învățat că unii programatori vor insista că codul lor este „auto-documentat”. Dacă nu sunteți familiarizat cu acest termen, se traduce prin „codul meu nu are comentarii”.

Soluții

Deși nimic nu este perfect, cred că există lucruri pe care le putem face pentru a ne îmbunătăți codul. Am descoperit Ghidul CSS de Harry Roberts cu ceva timp în urmă. Itt ține fidel promisiunii „Sfaturi și linii directoare la nivel înalt pentru scrierea CSS sănătoasă, gestionabilă și scalabilă”.

Comentarii

În timp ce liniile directoare CSS oferă detalii despre stilurile de comentarii, eu personal doar încerc să pun ceva pentru a-mi spune în viitor ce mă gândeam. Încep fiecare componentă cu un comentariu reprezentând titlul, detalii despre intenția componentei.

Când folosesc un preprocesor, stil anumite comentarii pentru a fi fie incluse în CSS, fie sărite de preprocesor. Încă lucrez la această parte și încerc să îmi iau obiceiul de a pune ceva , orice .

Orientare obiect

Orientarea către obiect este o paradigmă de programare care descompune lucrurile mari în lucruri mici. Din Wikipedia:

Programarea orientată pe obiecte (OOP) este o paradigmă de programare care reprezintă conceptul de „obiecte” […] care sunt de obicei instanțe ale claselor [și] sunt folosite pentru a interacționa între ele pentru a proiecta aplicații și programe de calculator.

Când vine vorba de CSS, numim acest lucru CSS orientat pe obiecte sau OOCSS . Conceptul de bază desparte structura elementului, de pielea elementului. Aceasta înseamnă că putem reutiliza cu ușurință orice model de design recurent, fără a reutiliza neapărat detaliile specifice de implementare în același timp. OOCSS se concentrează în mare măsură pe reutilizarea codului, ceea ce ne face mai rapid și poate menține dimensiunea bazei de cod redusă.

Mă gândesc la aspecte structurale precum scheletele; cadre comune care dau constructe cunoscute sub numele de obiect . Aceste obiecte sunt modele de design simple, care nu conțin orice produse cosmetice. Abstragem structura dintr-un set de componente pentru a avea un obiect generic.

Apoi, opțional, adăugăm stratul „piele” în structura noastră, astfel încât să putem oferi abstracțiilor un aspect și o senzație specifică. De exemplu (luat din Ghidul CSS):

 /**
 * Un obiect buton simplu, fără design. Extindeți acest obiect cu un skin `.btn--*`
 * clasa.
 */
.btn {
    display: inline-block;
    umplutura: 1em 2em;
    vertical-align: mijloc;
}

/**
 * Pielea nasturii pozitive. Extinde `.btn`.
 */
.btn--pozitiv {
    culoare de fundal: verde;
    culoare albă;
}

/**
 * Pielea nasturilor negative. Extinde `.btn`.
 */
.btn--negativ {
    culoare de fundal: roșu;
    culoare albă;
}

Aici vedem cum clasa .btn oferă pur și simplu structură unui element, dar nu are nimic în ceea ce privește cosmeticele. Putem extinde .btn cu o a doua clasă, cum ar fi .btn--positve pentru a oferi elementului respectiv un stil mai specific:

 <button class="btn btn--positive">OK</button>

Prefer mult să folosesc mai multe clase în HTML-ul meu, decât să folosesc ceva de genul @extend într-un preprocesor. Acest lucru îmi oferă mai multă vizibilitate în HTML-ul meu, permițându-mi să văd rapid ce clase sunt aplicate elementului meu. De asemenea, înseamnă că clasele mele nu sunt strâns legate de alte stiluri din CSS-ul meu. Ajută într-un fel OOCSS să urmeze conceptele de încapsulare .

BEM

BEM ( Block, Element, Modifier ), este o metodologie front-end dezvoltată la Yandex. BEM este de fapt o metodologie foarte completă și, sincer, nu am săpat în toate detaliile, dar ceea ce mă preocupă este pur și simplu convenția de numire.

Folosesc convenții de denumire asemănătoare BEM. Conceptul este același, dar sintaxa exactă poate diferi ușor.

BEM repartizează orele în trei grupe:

  1. Bloc: rădăcina sau baza unei componente
  2. Element: o componentă din interiorul unui bloc
  3. Modificator: o variație sau o extensie a blocului

O analogie de bază ( nu un exemplu):

 .câine {}
.dog__tail {}
.dog--mic {}

Elementele sunt delimitate cu două liniuțe de subliniere (__), iar modificatorii sunt delimitați cu două cratime (–).

În analogia de mai sus, vedem că .dog este Blocul, rădăcina elementului. Apoi, .dog__tail este un Element, este o parte mai mică a unui Bloc .dog . În cele din urmă, .dog--small este Modificator, o variantă specifică a blocului .dog . De asemenea, puteți aplica Modificatori la Elemente. de exemplu, am putea avea .dog__tail--short pentru a specifica din nou o variație a elementului dog__tail .

În unele cazuri, pot dori mai multe cuvinte pentru blocuri, elemente sau modificatori. În orice caz, acestea sunt separate cu o singură cratimă (-), iar clasele sunt întotdeauna scrise cu litere mici .

Preprocesoare

Am petrecut timp lucrând cu preprocesoare CSS în fluxul meu de lucru și, până acum, a fost incredibil de valoros. Preprocesoarele CSS preiau codul care este scris într-un limbaj preprocesat și îl convertesc în CSS vechi. Nu sunt CSS, ceea ce înseamnă că nu sunt obligați să fie aceleași reguli și limitări ale CSS. Deși CSS este grozav, nu întotdeauna ne permite să facem cu ușurință lucrurile pe care ne-am dori să le facem.

De exemplu, un lucru care ar fi foarte frumos în CSS este variabilele . Poate vrei ca ceva să aibă marginea din stânga a unui element la fel ca lățimea altuia și dintr-o dată cineva decide că acele numere trebuie să se schimbe. Deoarece sunt același număr și aspectul dvs. s-ar putea baza pe acel număr, trebuie să îl schimbați în mai multe locuri. Dar cu o variabilă ai putea să-l schimbi într- un singur loc și să-l reflectezi în întregul aspect. Desigur, la preprocesoare există mult mai mult decât doar variabile, dar acesta este un început!

În mod evident, nu trebuie să utilizați un preprocesor, dar cred că veți găsi majoritatea oamenilor care nu se vor întoarce înapoi. Știu că nu voi face. Câștigul în flexibilitate și lizibilitatea sporită sunt ceva la care pur și simplu nu pot renunța. Pur și simplu a putea folosi variabile și mixuri este suficient pentru a mă ține cuplat.

Există mai multe preprocesoare disponibile, dar singurele două la care m-am uitat și le-am folosit cu adevărat sunt LESS și SASS . Vă rugăm să aruncați o privire și să luați în considerare adăugarea uneia dintre acestea în fluxul dvs. de lucru, nu vă veți mai uita înapoi.

Încheierea

Ideea mea reală aici este că CSS poate fi mai bun. Totul poate fi mai bun. Cineva mi-a spus recent într-un comentariu la o postare de pe Reddit că „CSS nu are semantică”. Nu sunt din toată inima de acord. CSS 100%, fără îndoială poate fi semantic.

Utilizarea OOCSS și BEM oferă, de fapt, CSS-ului tău un sens foarte semantic. Acest lucru nu înseamnă că este ușor de la început, dar merită explorat. Combinați asta cu preprocesoarele CSS și aveți potențialul pentru CSS foarte lizibil, ușor de întreținut și scalabil .

De asemenea, aș dori să remarc că acest lucru nu numai că face CSS-ul dvs. (preprocesat sau nu) mai lizibil, dar vă face și HTML-ul mai lizibil, prin aplicarea numelor de clase semantice elementelor.

TL;DR

Ok, poate asta a fost mult – pentru a rezuma, scrie CSS mai bun făcând asta:

CSS orientat pe obiecte :

  • fiecare clasă face un lucru - o face bine, o face corect

Nume de clase de stil bloc, element, modificator (BEM) :

  • Bloc: .grid
  • Element: .grid__item (2 litere de subliniere)
  • Modificator: .grid--wide (2 cratime)

Preprocesoarele sunt minunate :

  • verificați-le: LESS – SASS
  • sau găsiți altele: 8 preprocesoare CSS pentru a accelera timpul de dezvoltare