CSS best practices: scrivere al meglio i fogli di stile

Imparate le regole di base, scrivere un foglio di stile CSS risulta essere un’operazione piuttosto semplice: diamo il nome a un elemento all’interno del DOM e richiamiamolo all’interno del CSS con gli stili che desideriamo applicargli. Voilà!

Nell’articolo di questa settimana, vorrei invece portarvi a scavare più a fondo nel mondo dei CSS per capire quali sono le buone norme da adottare che vi permetteranno di strutturare i vostri fogli di stile in modo pulito, comprensibile e mantenibile.

Premessa: non utilizzare stili inline! Potrebbe sembrare comodo in alcuni contesti, ma la mancata separazione tra contenuto e design rende il nostro sito molto più difficile da mantenere (oltre a non essere pulito). Se consideriamo, ad esempio, che a un certo punto potremmo volerne cambiare la grafica, si spenderà molto tempo a cercare e modificare gli stili dichiarati all’interno delle pagine rispetto ad averli in un foglio CSS. Oltretutto, la nostra pagina web diventerà più pesante e meno accessibile ai motori di ricerca, talvolta anche agli screen readers utilizzati da persone affette da disabilità.

Vediamo ora quali sono le best practices per realizzare fogli di stile CSS:

Unificazione delle regole di base dei CSS per tutti i Browser

Ciascun browser assegna delle regole di stile diverse agli elementi del markup HTML. Per avere una base uniforme da cui partire, i metodi più comuni sono di utilizzare un reset per azzerare tutti i parametri (come il reset di Eric Meyer) oppure di normalizzare le caratteristiche dei tag HTML utilizzando normalize.css. Il secondo metodo può essere preferibile rispetto al primo poichè agisce solo sulle differenze tra vari browser, mantenendo così gli stili di default utili senza doverli riscrivere. Per un approfondimento su normalize, consultate questo link.

Separazione in fogli di stile diversi

Quando il nostro foglio di stile comincia a comporsi di qualche migliaia di righe diventerà un po’ più difficile da mantenere e separarlo in fogli di stile differenti potrebbe migliorare il flusso di lavoro nonchè darà maggior consistenza al nostro progetto.

La separazione dei fogli di stile potrebbe essere pensata in modi differenti a seconda di come è strutturato il sito, ma di base potremmo avere:

  • layout.css: regole inerenti al layout (ad esempio: header, content, footer..)
  • grids.css: regole inerenti alle griglie del sito (ad esempio: blocks, columns..)
  • fonts.css: regole di eventuali font-face inclusi
  • tools.css: regole di eventuali strumenti utilizzati (ad esempio tabs, accordions..)
  • forms.css regole inerenti alle form del sito

Tienilo semplice e pulito

Cerchiamo di evitare concatenazioni molto lunghe di selettori, rischiando di essere troppo specifici inutilmente.
Se ad esempio abbiamo una struttura di questo tipo:

<footer class="site-info">
<div class="column-wrapper">
<div class="column sitemap">
<ul class="sitemap-links">
    <li>Home</li>
    <li>Area riservata</li>
...

</ul>
</div>
</footer>

Per dare lo stile all’elemento li del footer ci sarà sufficiente scrivere:

.site-info .sitemap-links > li{...}

Riduciamo al minimo le ripetizioni degli stili cercando di fare raggruppamenti di selettori o di specificare una classe che poi potremo richiamare su più elementi.

<div class="column">...</div>

Facciamo anche in modo che il nostro CSS sia leggibile, permettendogli di essere mantenibile per il futuro e per chi altro metterà mano al vostro codice. Generalmente si tende a scrivere codice CSS in due modi:

Su una riga

.site-info .sitemap-links > li{ color: #ccc; padding: 10px 0; border-bottom: 1px solid black;}

Su più righe

.site-info .sitemap-links > li{
color: #ccc;
padding: 10px 0;
border-bottom: 1px solid black;
}

Personalmente preferisco il secondo, mi permette di trovare a colpo d’occhio la regola che desidero modificare, il primo mi risulta essere molto confusionario quando ci sono molti stili associati. La scelta sta comunque a ciascuno.

Uso di selettori descrittivi

Quando assegniamo una classe al markup HTML, specifichiamo un nome che abbia semanticamente un senso e che ci possa permettere di fare una rapida associazione all’elemento riferito. E’ inoltre buona norma cercare di spiegare il contenuto a cui il selettore fa riferimento e non al look: il design potrebbe cambiare nel tempo o le media queries agire radicalmente su di esso per i diversi device.

Non usare selettori ID

Attualmente sul web esiste un ricco dibattito in merito (se siete curiosi, leggete la difesa degli ID di John Allsop). Il nostro parere è di evitare i selettori ID e di usare sempre le classi per dare design al contenuto al nostro sito, per tre principali ragioni:

  • L’id è univoco e non può essere utilizzato in più parti della pagina. In questo modo non potremo assegnare lo stile definito nel CSS a più elementi.
  • L’id è molto specifico e ha quindi elevata priorità anche su selettori di classi specifiche, rischiando di farci incappare in situazioni non desiderate. Consideriamo questo semplice esempio: una lista di social che vorremmo inserire in più porzioni della nostra pagina rischia di perdere gli stili ad essa associati.
  • Come conseguenza del secondo punto, l’id rende il sito difficile da mantenere, soprattutto quando si lavora in team o su siti complessi. Quando infatti non si conosce a menadito di cosa un sito si compone, con gli ID rischiamo di sovrascrivere con molta facilità regole specificate in altri punti di altre pagine.

Limitare l’uso di tag generici

Un discorso opposto a quello sugli ID è di usare il meno possibile tag generici. In questo caso, si rischiano di avere delle situazioni indesiderate di ereditarietà, che ci forzerebbero a una sovrascrittura di regole non voluta. Se per ragioni particolari abbiamo bisogno di utilizzarli all’interno del nostro foglio di stile, possiamo fare affidamento sulle discendenze dirette:

.main-navigation > li{...}

Un’altra ragione per la quale è meglio evitare di dare stili a tag generici è quella di separare quanto possibile il CSS dal DOM della nostra pagina, in modo da non creare delle dipendenze dell’uno con l’altro, in vista anche di un futuro riciclo.

E per concludere.. minimizzare e unificare

Quando siamo pronti per andare online, ci sono alcuni accorgimenti di ottimizzazione che possiamo adottare con i CSS. Il primo tra questi, come per gli script, è di minificarne i contenuti per ottenere file con un peso minore (ad esempio con cleancss.com). Il secondo è quello di unificare i diversi CSS che abbiamo elaborato in un unico file, per ridurre al minimo le richieste HTTP del nostro sito. Per questa seconda operazione, sconsigliamo l’uso di file javascript, poichè si rischiano di fare più chiamate rispetto a tenere i CSS separati. Consigliamo invece l’utilizzo di Preprocessor o di framework che fanno entrambe le operazioni server-side automaticamente. Se state sviluppando un sito in WordPress ecco un utile plugin che potrebbe fare al caso vostro.

Lascia un commento

Tutti i campi sono obbligatori.
L'indirizzo email non verrà pubblicato