BEM – Organizziamo il Web Design

Analizziamo l’importanza dell’approccio con metodi di buona scrittura come il BEM per il Web Design: migliorare e ottimizzare il codice scritto dal team è possibile anche nel Frontend :).

Cos’è BEM

Il Gentlemen’s Agreement dei CSS

Quello che in linguaggio informatico viene etichettato con un acronimo può essere di solito anche chiarito in italiano corrente, ma fa molto meno figo.

In particolare BEM, che sta per ‘Block – Element – Modifier’, altro non è che una norma ortografica per la buona scrittura di CSS. Un Gentlemen’s Agreement utile al lavoro in team e alla manutenzione futura del foglio CSS.

La specificità dei selettori CSS3
(moduli pubblicati dal W3C tra il 2011 e il 2013)

Con l’introduzione dei CSS3 (moduli pubblicati dal W3C tra il 2011 e il 2013) e l’aumento dei selettori disponibili, le potenzialità erano diventate davvero infinite, e poteva capitare di trovare selettori combinati come:

div.contenitore ul.lista > li.elemento span:nth-of-type(3) a:hover {
    background-color: #FFFFFF;
}

Per gli web designer duri e puri, soprattutto quelli che non utilizzano un precompilatore come SASS o LESS, questo tipo di selettori suscitarono inizialmente un enorme entusiasmo: WOW! Posso attribuire uno stile specifico sull’hover del terzo span del li con classe ‘elemento’ figlio diretto dell’elenco con classe ‘lista’  discendente del div con classe ‘contenitore’!!!!

Fantastico, una precisione mai vista prima. Il problema era la manutenibilità e la leggibilità del codice, che purtroppo peggioravano drasticamente.

Da qui (e da altre esigenze di cui parlerò più avanti) l’idea di creare una serie di norme di buona scrittura, rispettando le quali poter avere uno standard di creazione CSS più utile al lavoro in team; ecco la nascita di BEM per il Web Design.

La sintassi BEM

HTML e CSS

La sintassi BEM segue rigidamente la struttura BLOCCO – ELEMENTO – MODIFICATORE. Portiamo ad esempio la creazione degli stili per i bottoni del sito:

HTML

<a class="btn btn--big btn--orange" href="http://nomesito.com">
 <span class="btn__price">10 €</span>
 <span class="btn__text">Metti nel carrello</span>
</a>

BLOCCO:

1. 1. Il nome del blocco viene assegnato con l’attributo CLASS e non con ID

1. 1. un blocco è totalmente INDIPENDENTE da altri elementi blocco

1. Il nome della classe può essere scritto con lettere, numeri o trattini

/* Blocco */
.btn {}

ELEMENTO:

1. 1. Gli elementi sono dipendenti dai blocchi

1. 1. Il nome dell’elemento viene assegnato con l’attributo CLASS e non con ID

1. 1. Hanno nomi semanticamente rilevanti e leggibili e la prima parte è uguale al nome del blocco a cui si riferiscono (es: class=”btn__price” è chiaramente un elemento del blocco “btn”)

1. Il nome della classe può essere scritto con lettere, numeri, trattini e underscore (di solito, il nome è composto dal nome del blocco, poi due underscore, poi un’altra parola semanticamente rilevante)

/* Elemento - che dipende dal blocco*/ 
.btn__price {}

NB: si utilizza SOLO il nome della classe nella scrittura del CSS, senza sudditanze da altri elementi, quindi sintassi come queste non sono corrette:

div.btn__price {}

MODIFICATORE:

1. 1. Il modificatore cambia lo stile del blocco o dell’elemento

1. 1. La classe del modificatore viene assegnata, nell’HTML, subito dopo quella che identifica il blocco o l’elemento, e ripete al suo interno il nome della classe del blocco o dell’elemento stesso (es: class=”btn btn–spento”)

1. Il nome della classe può essere scritto con lettere, numeri, trattini e underscore (come per gli elementi, ma è utile adottare una differenziazione formale, per esempio due trattini invece dell’underscore)

/* Modificatore - che cambia lo stile del blocco o dell’elemento*/
.btn--orange {} 
.btn--big {}

/*Oppure anche utilizzato con elementi figlio:*/

.btn--orange .btn__text{}

Un appunto sull’utilizzo dei trattini

Anche se le regole di nomenclatura di BEM prevedono l’utilizzo dei trattini nel nome dei blocchi e degli elementi, molti designer hanno concluso che la leggibilità del codice migliora notevolmente se questi vengono utilizzati solo per individuare la classe del modificatore.
Nel caso il nome sia composto da due parole, si può assolvere alla funzione del trattino ricorrendo al camel case; sarà quindi più comodo trasformare un elemento blocco
“main-menu” in “mainMenu”:

Esempio applicato su classe modificatore:

main-menu__link-right--default

Diventa

mainMenu__linkRight--default

Pregi

1. Per ogni blocco, prima di scrivere nuovo codice CSS, si può facilmente controllare se esistono già elementi o modificatori che assolvono la nostra necessità.
2. La lettura del codice è semplificata, ogni nome di classe è autoesplicativo e le dipendenze rendono più chiara la struttura dei componenti della pagina (btn__price sarà facilmente riconducibile al blocco btn anche senza leggere altro)
3. Designer e developer possono utilizzare una sintassi condivisa e migliorare l’interazione del team, inoltre diventa più semplice riprendere in mano un lavoro dopo mesi, avendo uno standard di scrittura.
4. Si riduce lo SCOPE della classe CSS, rendendolo più prevedibile: una classe generica .red {color: red;} quanti elementi nel sito influenzerà? Modificandola per una pagina quali ripercussioni ci saranno sull’intero sito? Con la sintassi BEM si evitano nomi generici che possono diventare degli ‘intoccabili’ nel codice CSS.
5. Si riducono gli errori di duplicazione delle classi: non utilizzando classi generiche sarà improbabile creare due classi con lo stesso nome che vadano in conflitto (magari da parte di due componenti del team diversi)
   .red {color: red;} e .red {background-color: red;}
6. Tutto ha una classe propria e si evitano selettori troppo nidificati, che diventano troppo specifici e non riutilizzabili.
   

Difetti

1. 1. Verbosità del codice HTML: i nomi di classe sono piuttosto lunghi; prendiamo, ad esempio, un form che sia un blocco con modificatore, ed abbia al suo interno degli elementi con a loro volta altri modificatori:
      

      <form class=”form form--newsletter”>
       <input type=”text” class=”form__input form__input--disabled”>
      </form>

1. 1. Possono sorgere dubbi di nomenclatura con gli elementi nidificati: In un elemento blocco, come chiamerò i figli di un elemento? Evitiamo nomi di elementi tipo:header__right__form__button
      O, ancora peggio, nomi di modificatori come: header__right__form__button–disabled
      Molti suggeriscono di utilizzare sempre elementi con riferimento solo al blocco, anche se sono nidificati. Ad esempio:
      

      <div class=”header”>
       <div class=”header_menu”>
       <a href=”fuffa.html” class=”header_link”>Fuffa</a>
       </div>
      </div>

1. 1. Non è possibile utilizzare CSS scritti in BEM senza un HTML che sfrutti lo stesso standard (quindi su siti vecchi o codice già scritto non è applicabile).

1. Si tratta di uno STANDARD NON STANDARD: paradossalmente, ciò che nasce per uniformare il metodo di scrittura, viene spesso interpretato in maniera diversa dagli sviluppatori, proprio perché a sua volta nato senza una regolamentazione precisa e soprattutto perché SEMPRE FUNZIONANTE, essendo semplicemente un modo di scrittura dei CSS.
   Per questo motivo, spesso si riscontrano forti discrepanze: a partire banalmente dall’uso non uniforme dei trattini e degli underscore,  passando dal sistema di scrittura degli elementi nidificati (come abbiamo già visto), fino ad arrivare all’utilizzo delle classi dei modificatori da sole, soprattutto da parte di coloro che utilizzano precompilatori CSS come ad esempio SASS.

Facciamo un esempio:

Secondo la sintassi BEM “standard” un modificatore deve essere specificato nell’attributo CLASS, subito dopo la classe del blocco (o dell’elemento) in modo da ereditare tutte le caratteristiche del blocco stesso e applicare le modifiche del modificatore, che possono integrarsi o sovrascrivere le precedenti.

<input class=”btn btn--disabled”>

Erediterà ad esempio questi CSS

.btn{
 border: rounded;
 background: orange;
 }
.btn--disabled{
 background: grey;
 }

Ma se si utilizza un precompilatore SASS, al modificatore può essere applicato lo stile del blocco grazie alla funzione @extend

.btn{
 border: rounded;
 background: orange;
 }
.btn--disabled{
 @extend .btn;
 background: grey;
 }

Producendo nel foglio CSS questo stile per la classe del modificatore:

.btn--disabled{
 border: rounded; /*stile ereditato dall’elemento blocco*/
 background: grey;
 }

A questo punto ovviamente non ha alcun senso richiamare la classe blocco, di conseguenza gli sviluppatori SASS tenderanno ad utilizzare le classi modificatore da sole, snellendo drasticamente il codice HTML, ma contravvenendo inevitabilmente a una delle regole di sintassi BEM.

<input class=”btn--disabled”>

Conclusioni

Secondo il mio parere il mondo dei CSS è ancora lontano dall’essere finalmente domato da uno standard universale, seppur gli sforzi in questo senso debbano essere apprezzati e incentivati. Ben venga dunque BEM per il Web Design, che seppur non soddisfa appieno i requisiti di uniformità globale, può comunque rappresentare un ottimo metodo di lavoro all’interno di un team.
Inoltre la particolare nomenclatura autoesplicativa lo rende uno strumento valido nella creazione di codice facilmente modificabile all’esterno del team stesso, anche da coloro che non conoscono affatto i principi di BEM; è quindi fortemente suggerito nella creazione di librerie e framework front-end (es. Bootstrap) che devono essere utilizzate da un bacino di persone più ampio.

L’estrema verbosità del codice può essere parzialmente schivata attraverso l’utilizzo di precompilatori come SASS e anche grazie ad alcuni escamotage (L’utilizzo oculato dei trattini e del camel case, ad esempio).

Ed io, utilizzerei BEM per un nuovo progetto?

Mi piacerebbe adottarlo, senza dubbio. Certo, dopo tanti anni di lavoro ognuno di noi sviluppa un proprio metodo di scrittura con il quale certamente si trova a proprio agio, ed è sempre difficile rimodellare il proprio schema mentale quando si tratta di processi ben rodati. Ma il nostro mestiere è un continuo mettersi in gioco, imparare e crescere! E BEM è un’ottima base di partenza per progetti complessi, ordinato e pulito come un bel prato inglese… Su cui, al bisogno, si può sempre piantare un rovo di rose 😉

CSS Day e GrUSP

Il riferimento iniziale al quale è dovuta la scelta del tema per questo articolo è il CSSDay tenutosi a Faenza a marzo (2018), che mi ha permesso di approfondire tematiche che già parzialmente conoscevo e di entrare in contatto con le nuove possibilità offerte dalla crescita del linguaggio CSS.

Grazie quindi a GrUSP (associazione no-profit nata per promuovere l’utilizzo di buone pratiche di sviluppo) per l’organizzazione della giornata e a Giuneco che mi ha dato la possibilità di partecipare.