Sfaturi pentru structura CSS pentru site-urile de afaceri (sau oricare din aceste aspecte)

Publicat: 2020-12-17

CSS și HTML sunt ușor de înțeles. Cu toate acestea, este nevoie de ani de practică pentru a afla despre cele mai bune abordări arhitecturale atunci când construiți site-uri web (și aplicații) într-un mod care le face reutilizabile, care să poată fi întreținute în viitor și să îi facă pe dezvoltatori fericiți.

Ce se înțelege prin arhitectură aici? Este structura codului CSS. Modul în care îl separați în fișiere, regulile din spatele numelor de clase, adâncimea selectorilor, modul în care cascade, ceea ce este moștenit, modul în care configurați componente, pagini, elemente și modificatori.

Pentru a aplica cele mai bune practici la toate aceste componente ale site-ului web cu sute de pagini, diferite tipuri de conținut, vizualizări de ecran, cazuri majore și având în vedere adăugarea mai multor elemente de top și modificarea celor existente este partea dificilă.

Construiți cu componente, nu cu pagini

Aceasta este una dintre părțile majore de luat în considerare. Nu ar trebui să aranjați pe baza paginii pe care vă aflați. Nu faceți o .homepage ... {} stiluri. Dacă pagina dvs. are o secțiune, stilizați secțiunea. Cu aceasta, îl puteți reutiliza și pe alte pagini. Dacă aveți un buton, stilizați butonul ca .button {} și refolosiți-l în altă parte. Este valabil pentru toate vizualizările.

Acesta este cel mai comun sfat și cea mai performantă abordare (până acum) pe care o puteți utiliza.

Stilul având în vedere componentele

Acum, cum gestionați diferențele specifice paginii? Pentru că acesta este motivul cel mai frecvent pentru a stiliza pe pagină? Ei bine, există câteva abordări:

Folosiți modificatori.

În „BEM”, „M” înseamnă Modificator. Acesta este aspectul .block__child – modificator. Chiar dacă nu utilizați BEM, modificatorii există oricum. Dacă există o variantă a unei componente sau a unei secțiuni, adăugați un modificator pentru aceasta.

În mod ideal, proiectantul ar trebui să fie atent și să mențină variațiile la minimum pentru a menține codul curat, dar nu ar trebui să vă fie frică să adăugați mai multe la acesta. În mod ideal, variațiile ar trebui doar să suprascrie câteva proprietăți și ar trebui să funcționeze cu același marcaj. Este o modalitate bună de a aborda componentele în faza HTML - adăugați etichetele de care veți avea nevoie și păstrați-le consecvente pe site. Nu adăugați altele noi din cauza unei clase de modificatori.

Modificator element bloc

Stilează componentele copiilor.

Cealaltă abordare este stilul bazat pe context. Un buton este întotdeauna un buton, are clasa sa .button și toate, dar îl puteți regla în continuare dacă face parte dintr-o altă componentă. În general, aceasta nu este o idee bună, deoarece creează inconsecvențe, dar este, de asemenea, un caz de utilizare destul de realist. În caz contrar, ați ajunge cu 20 de modificatori cu nume ciudate.

Stilurile din punct de vedere contextual sunt atunci când stilizați o componentă numai dacă este un copil al altuia. Să luăm de exemplu o fișă de articol. Are stilurile sale în mod implicit. Dar dacă face parte dintr-o secțiune colorată, cu un text lateral, designul necesită ca cardul să aibă câteva alte elemente în jurul său (cum ar fi formele animate etc.).

În acest caz, creați stilul cu selectorul .parent .card {}. Va trebui să suprascrieți doar câteva proprietăți, așa cum ați face cu un modificator. Când faceți acest lucru, cardul în sine nu adaugă mai multă complexitate stilurilor sale, dar se va comporta în mod corespunzător în cazul respectiv.

Când vă gândiți la acest lucru, puteți vedea, de asemenea, cum poate fi aplicat „pe pagină”. Dacă există unele cazuri de margini ciudate în proiectare și există unele diferențe minore față de vizualizările standard ale componentelor (și modul în care acestea interacționează toate împreună), atunci puteți stiliza exact acest lucru cu selectorul .homepage {}. Nu uitați să folosiți acest lucru cu moderație. Din experiența noastră, astfel de stiluri rareori depășesc câteva linii de cod.

Notă importantă de adăugat: stilurile contextuale NU sunt o practică bună în general. În mod ideal, nici măcar nu ar trebui să ai nevoie de asta. De cele mai multe ori, ai avea modificatori care ar trebui să facă treaba suficient de bine. Chiar dacă este realist în unele versiuni, scufundarea prea adâncă într-un cod bun abstractizat cu reguli stricte poate fi prea costisitoare.

Lucrați în secțiuni

Majoritatea site-urilor web de afaceri (precum și multe altele) separă conținutul în secțiuni. Fiecare secțiune este o componentă singură cu o clasă de modificator care definește diferitele proprietăți. O sugestie pentru a merge cu structura claselor ar fi:

Separați paginile de destinație în secțiuni

  • section.section-container - acesta ar putea fi „numele componentei” dacă doriți, care conține umpluturile / marginile consistente sau orice este necesar.
  • section.section-border-top - este un modificator. Acest lucru nu folosește BEM, dar îl puteți „traduce” în secțiune-container-margine, dacă este necesar.
  • section.section-welcome - ar fi numele secțiunii.

Convenția de numire din nou este irelevantă aici. Cu astfel de secțiuni, veți câștiga libertatea de a ajusta stilurile la componentele reutilizabile în cazurile de margine create de design (fie din cauza inconsecvențelor care trebuie urmate sau doar a vizualizărilor mai complicate).

Separarea fișierelor

Cel mai probabil ați folosi Sass sau un alt preprocesor similar. În ceea ce privește separarea fișierelor, există multe abordări, dar cea pe care o luăm urmează următoarea structură generală:

  • General - General, de obicei, constă din cod de configurare, cum ar fi funcționarea unei grile, stiluri pentru etichete HTML, resetări / normalizator, unele stiluri specifice CMS și aprecieri.
  • Pagini - Stilurile de pagină, așa cum s-a explicat mai sus. În mod ideal, ar trebui să păstrați foarte puțin cod aici.
  • Componente - nucleul construcției - diferitele componente se află aici. Un sfat este că puteți avea „elemente” sau „misc” care ar încadra bucăți mai mici de componente într-un singur fișier în loc de 80 de fișiere. Cele mai mari, desigur, ar trebui să meargă în fișiere separate.
  • Aspect - Stiluri globale, de exemplu, în antet, subsol și apoi aspecte de pagină, modificatori ai grilei dvs. și așa mai departe.
  • Pluginuri - Orice lucru extern generat dintr-un plugin, extensie sau orice altceva. Este frumos să le separați, deoarece le puteți reutiliza în alte proiecte.

Păstrați selectoarele curate

Un semn bun al codului curat este cât de simplu arată. Fără proprietăți ciudate, totul are scopul său, există o indentare scăzută. Selectoarele „Arătând inteligent” atunci când nu este necesar nu vă fac codul „cool”. Dacă puteți înlocui ceva de genul #container> .row div [rel = ”ceva”] cu .rel-something (imaginați-vă că este un nume semnificativ de clasă), atunci ar trebui să actualizați puțin marcajul. Scopul acestui lucru este de a menține totul mai simplu.

Păstrați indentările scăzute. Rareori trebuie să treci peste trei niveluri. Să vedem de exemplu o clasă .entry:


.entry {...}
.entry-title {...}

Vedeți că nu este nevoie să introduceți cu adevărat .entry-title în interiorul .entry. Mai târziu, când adăugați un modificator în fișier, puteți avea .entry-modificator {} și .entry-modificator .entry-title {}

Cu această abordare, suprascrierea stilurilor în viitor este mult mai ușoară. Să aruncăm o privire la un alt exemplu obișnuit: aveți marcajul nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Acum, pentru stil, tot ce aveți nevoie este:


.site-nav {} - componenta 1

.list-menu {} - componenta 2
.list-menu .list-item {}
.list-menu a {}

Dacă ați avut mai multe componente în interior, cum ar fi drop-down-uri suplimentare, le puteți cuibări direct în .list-menu. Nu trebuie să scrieți .site-nav .list-menu .list-item .dropdown {} (4 nivele adâncime) atunci când puteți avea două niveluri de .list-menu .dropdown {}

Scrieți mai multe nume de clase abstracte pentru modificatori

Acesta este pentru mentenabilitate. Un exemplu neobișnuit pe care l-ați găsi în postări similare ar fi să nu setați o variabilă de culoare la $ roșu, în loc să o setați la $ primar sau $ secundar.

Motivul este că atunci când este necesară o modificare pe linie, variabila $ roșu ar produce albastru. Este mult mai logic că doriți să vă schimbați culoarea primară , nu culoarea roșie , nu?

La fel ar fi valabil și pentru alte tipuri de culori și proprietăți. Să presupunem că aveți linii care separă un anumit conținut (cum ar fi eticheta <hr>). Numiți acea .line-dash pentru că este întreruptă. Are perfect sens. Dar apoi vine o schimbare și trebuie punctată. Te duci și îl redenumești în .line-dotted? Acesta nu este un modificator, aceasta este componenta. În loc de aceasta, l-ați putea numi .line-separator. Și apoi, dacă doriți să fiți specific, puteți adăuga un modificator pentru .dotted sau .dashed. Acest tip de denumire este adesea ceea ce necesită cel mai mult timp atunci când construiți un site.

În concluzie

Există nenumărate practici bune și rele. O modalitate de a obține rezultate mai bune este definirea regulilor și respectarea acestora. Este greu să veniți cu astfel de reguli, deci o sugestie bună ar fi să navigați pe web și să încercați să adunați toate informațiile posibile despre arhitectură, cum ar fi convențiile de denumire, bune practici, cum să scrieți cod care poate fi întreținut și multe altele.

Pentru a produce un cod bun este nevoie de mult timp și de sute de mii de linii de cod. În timp ce faceți toate acestea, întrebați-vă întotdeauna „Ar scara asta?”, „Pot să o reutilizez?”, „Am suprascris prea mult?”, „Are sens să o denumesc așa?”. Cu cât faci mai mult acest lucru, cu atât deciziile tale vor deveni mai optime și cu atât viteza de lucru se va îmbunătăți.

O investiție în fundamentele bune va avea ca rezultat mai puțin înainte și înapoi în proiectele dvs. și orice schimbări viitoare care trebuie să aibă loc vor fi mult mai ușor de implementat.