Suggerimenti per la struttura CSS per i siti Web aziendali (o qualsiasi altro per tale questione)

CSS e HTML sono semplici da capire. Tuttavia, sono necessari anni di pratica per apprendere i migliori approcci architettonici quando si creano siti Web (e app) in un modo che li renda riutilizzabili, manutenibili in futuro e che mantenga gli sviluppatori felici.

Cosa si intende per architettura qui? È la struttura del codice CSS. Il modo in cui lo dividi in file, le regole dietro i nomi delle classi, la profondità dei selettori, il modo in cui si sovrappone, cosa viene ereditato, come imposti componenti, pagine, elementi e modificatori.

Applicare le migliori pratiche a tutti questi componenti del sito Web con centinaia di pagine, vari tipi di contenuti, visualizzazioni di schermate, casi limite e con la considerazione di aggiungere altro in cima e modificare quelli esistenti è la parte difficile.

Crea con componenti, non con pagine

Questa è una delle parti principali da considerare. Non dovresti applicare lo stile in base alla pagina in cui ti trovi. Non creare stili .homepage ... {}. Se la tua pagina ha una sezione, applica uno stile alla sezione. Con ciò, puoi riutilizzarlo anche su altre pagine. Se hai un pulsante, definiscilo come .button {} e riutilizzalo altrove. È valido per tutte le visualizzazioni.

Questo è il consiglio più comune e l'approccio migliore (finora) che puoi utilizzare.

Ora, come gestisci le differenze specifiche della pagina? Perché questo è il motivo più comune per applicare uno stile per pagina? Bene, ci sono alcuni approcci:

Usa i modificatori.

In "BEM", la "M" sta per modificatore. Questo è l'aspetto del modificatore .block__child. Anche se non usi BEM, i modificatori esistono comunque. Se c'è una variazione a un componente o una sezione, aggiungi un modificatore per essa.

Idealmente, il progettista dovrebbe essere premuroso e ridurre al minimo le variazioni per mantenere pulito il codice, ma non dovresti aver paura di aggiungerne di più. Le variazioni dovrebbero idealmente sovrascrivere solo alcune proprietà e dovrebbero funzionare con lo stesso markup. È un buon modo per avvicinarsi ai componenti nella fase HTML: aggiungi i tag di cui avrai bisogno e mantienili coerenti in tutto il sito. Non aggiungerne di nuovi a causa di una classe modificatore.

Stile componenti per bambini.

L'altro approccio è quello di stile basato sul contesto. Un pulsante è sempre un pulsante, ha la sua classe .button e tutto il resto, ma puoi comunque regolarlo se fa parte di un altro componente. Questa generalmente non è una buona idea in quanto crea incongruenze, ma è anche un caso d'uso abbastanza realistico. Altrimenti, ti ritroveresti con 20 modificatori con nomi strani.

Gli stili contestuali sono quando si definisce uno stile solo se è figlio di un altro. Prendiamo ad esempio una scheda articolo. Ha i suoi stili per impostazione predefinita. Ma se fa parte di una sezione colorata con del testo a lato, il design richiede che la carta abbia alcuni altri elementi intorno (come forme animate, ecc.).

In tal caso, esegui lo stile con il selettore .parent .card {}. Dovrai solo sovrascrivere alcune proprietà come faresti con un modificatore. Quando lo fai, la carta stessa non aggiunge più complessità ai suoi stili, ma si comporterà comunque correttamente in quel caso limite specifico.

Quando pensi a questo, puoi anche vedere come può essere applicato "per pagina". Se ci sono alcuni casi limite strani nel design e ci sono alcune piccole differenze rispetto alle viste dei componenti standard (e il modo in cui interagiscono tutti insieme), allora puoi modellare proprio questo con il selettore .homepage {}. Ricorda solo di usarlo con parsimonia. Nella nostra esperienza, tali stili raramente superano poche righe di codice.

Nota importante da aggiungere: gli stili contestuali NON sono una buona pratica in generale. Idealmente non dovresti nemmeno averne bisogno. Il più delle volte, avresti modificatori che dovrebbero fare il lavoro abbastanza bene. Anche se in alcune build è realistico, immergersi troppo in profondità in un buon codice astratto con regole rigide può essere troppo costoso.

Lavora in sezioni

La maggior parte dei siti web aziendali (così come molti altri) separa i contenuti in sezioni. Ogni sezione è un componente a sé stante con una classe modificatore che definisce le varie proprietà. Un suggerimento per andare con la struttura delle classi sarebbe:

• section.section-container - questo potrebbe essere il "nome del componente" se vuoi, che contiene i padding / margini coerenti o qualsiasi cosa sia necessaria.
• section.section-border-top - è un modificatore. Questo non usa BEM, ma puoi "tradurlo" in sezione-contenitore-bordo se necessario.
• section.section-welcome - sarebbe il nome della sezione.

Anche in questo caso la convenzione di denominazione è irrilevante. Con tali sezioni, si otterrebbe la libertà di adattare gli stili ai componenti riutilizzabili nei casi limite creati dal progetto (sia a causa di incongruenze che devono essere seguite o solo per visualizzazioni più complicate).

Separazione dei file

Molto probabilmente useresti Sass o un altro preprocessore simile. In termini di separazione dei file, ci sono molti approcci, ma quello che adottiamo segue la seguente struttura generale:

• Generale - Generale di solito consiste in codice di configurazione come far funzionare una griglia, stili per tag HTML, ripristini / normalizzatore, alcuni stili specifici per CMS e simili.
• Pagine: gli stili di pagina come spiegato sopra. Idealmente, dovresti tenere molto poco codice qui.
• Componenti: il nucleo della build: i vari componenti risiedono qui. Un suggerimento è che puoi avere "elementi" o "misc" che si adatterebbero piccoli pezzi di componenti in un file invece di 80 file. Quelli più grandi, ovviamente, dovrebbero idealmente andare in file separati.
• Layout: stili globali, ad esempio, sull'intestazione, il piè di pagina e quindi i layout di pagina, i modificatori della griglia e così via.
• Plugin: qualsiasi cosa esterna generata da un plugin, un'estensione o altro. È bello separarli in quanto puoi riutilizzarli in altri progetti.

Mantieni puliti i selettori

Un buon segno di codice pulito è quanto sia semplice. Nessuna proprietà strana, tutto ha il suo scopo, c'è una bassa rientranza. I selettori "intelligenti" quando non necessari non rendono il codice "interessante". Se puoi sostituire qualcosa come #container> .row div [rel = ”something”] con .rel-something (immagina che sia un nome di classe significativo), allora dovresti semplicemente aggiornare un po 'il markup. L'obiettivo di questo è mantenere tutto più semplice.

Mantieni le rientranze basse. Raramente hai bisogno di superare più di tre livelli. Vediamo ad esempio una classe .entry:

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

Nota che non c'è davvero bisogno di far rientrare .entry-title all'interno di .entry. Successivamente, quando aggiungi un modificatore al file, puoi avere .entry-modifier {} e .entry-modifier .entry-title {}

Con questo approccio, la sovrascrittura degli stili in futuro è molto più semplice. Diamo un'occhiata a un altro esempio comune: hai il markup di nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Ora, per lo stile, tutto ciò di cui hai bisogno è:

.site-nav {} - componente 1

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

Se hai più componenti all'interno, come altri menu a discesa, puoi nidificarli direttamente all'interno di .list-menu. Non devi scrivere .site-nav .list-menu .list-item .dropdown {} (4 livelli di profondità) quando puoi avere due livelli di .list-menu .dropdown {}

Scrivi più nomi di classe astratti per i modificatori

Questo vale per la manutenibilità. Un esempio comune che potresti trovare in post simili sarebbe quello di non impostare una variabile di colore su $ red, la dovresti invece impostare su $ primary o $ secondary.

Il motivo è che quando è necessaria una modifica su tutta la linea, la variabile $ red restituisce il blu. Ha molto più senso che tu voglia cambiare il tuo colore primario , non il tuo colore rosso , giusto?

Lo stesso vale per altri tipi di colori e proprietà. Supponiamo che tu abbia righe che separano alcuni contenuti (come il tag <hr>). Lo chiami .line-dash perché è tratteggiato. Ha perfettamente senso. Ma poi arriva un cambiamento e deve essere punteggiato. Vai a rinominarlo in .line-punteggiato? Questo non è un modificatore, questo è il componente. Invece di questo, puoi chiamarlo come separatore di riga. E poi, se vuoi essere specifico, puoi aggiungere un modificatore per .dotted o .dashed. Questo tipo di denominazione è spesso ciò che richiede più tempo durante la creazione di un sito.

In sintesi

Ci sono innumerevoli buone e cattive pratiche. Un modo per ottenere risultati migliori è definire le regole e seguirle. È difficile trovare regole del genere, quindi un buon suggerimento sarebbe quello di navigare sul Web e cercare di raccogliere tutte le informazioni possibili sull'architettura come convenzioni di denominazione, buone pratiche, come scrivere codice mantenibile e altro ancora.

Per produrre un buon codice ci vuole molto tempo e centinaia di migliaia di righe di codice. Mentre fai tutto ciò, chiediti sempre "Sarebbe in scala?", "Posso riutilizzarlo?", "Ho sovrascritto troppo?", "Ha senso chiamarlo così?". Più lo fai, più ottimali diventeranno le tue decisioni e più la tua velocità di lavoro migliorerà.

Un investimento in buone basi si tradurrà in meno avanti e indietro sui tuoi progetti e qualsiasi cambiamento futuro che dovrà avvenire sarà molto più facile da implementare.