Sass Guidelines

Sintassi e formattazione

Se me lo chiedeste, la prima cosa che una guida di stile dovrebbe fare è descrivere il modo in cui vogliamo che il nostro codice sia scritto.

Quando diversi sviluppatori sono coinvolti nello scrivere CSS sullo stesso progetto, è solo questione di tempo prima che uno di loro cominci a scrivere alla sua maniera. Delle linee guida sul codice, che spingono alla coerenza, non servono solo a prevenire ciò, ma aiutano anche quando c’è da leggere e aggiornare il codice.

Ispirandoci senza vergogna a CSS Guidelines vogliamo:

• indentare con due (2) spazi, non utilizzando tab;
• avere righe di 80 caratteri, se possibile;
• scrivere le regole css su più righe;
• usare in modo ragionato le righe bianche.

// Yep
.foo {
  display: block;
  overflow: hidden;
  padding: 0 1em;
}

// Nope
.foo {
    display: block; overflow: hidden;

    padding: 0 1em;
}

// Since Sass indented-syntax forces those coding standards
// There is no wrong way of proceeding
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Stringhe

Che ci crediate o no, le stringhe giocano un ruolo fondamentale in CSS così come in Sass. Molti valori CSS possono essere sia lunghezze che identificatori, perciò è molto importante rispettare le linee guida quando si ha a che fare con le stringhe in Sass.

Codifica

Per evitare possibili guai con la codifica dei caratteri, è altamente cosigliato forzare l’enconding UTF-8 nel foglio di stile principale usando la direttiva @charset. Fate attenzione che sia il primo elemento del foglio di stile e che non ci siano caratteri a precederlo.

@charset 'utf-8';

@charset 'utf-8'

Apici

CSS non ha bisogni di apici per le stringhe, nemmeno per quelle che contengono spazi. Prendete la dichiarazione font-family: non importa se si usano gli apici per i nomi dei font oppure no.

Per questo motivo, Sass non richiederebbe di usare gli apici per le stringe. Meglio ancora (e per fortuna!) una stringa con gli apici è uguale a una senza ('abc' è uguale ad abc).

Detto questo però, i linguaggi che non richiedono gli apici per le stringhe sono una minoranza, quindi in Sass le stringhe dovrebbero sempre essere comunque messe dentro singoli apici ('). È preferibile usare gli apici singoli rispetto ai doppi perchè più facili da digitare in una tastiera qwerty. Ci sono inoltre diverse ragioni per questa scelta, oltre alla coerenza con altri linguaggi, incluso il cugino JavaScript:

• i nomi dei colori sono considerati colori solo quando non hanno gli apici, il che può portare diversi problemi;
• molti degli strumenti di evidenziazione della sintassi non funzionano su stringhe senza apici;
• aiuta la leggibilità;
• non c’è nessuna ragione per non aggiungere gli apici alle stringhe.

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Stringhe come valori CSS

Valori specifici CSS come initial o sans-serif (alias: identificatori CSS) non hanno bisogno di apici. Dichiarazioni come font-family: 'sans-serif' non verranno applicate, in quanto CSS si aspetta un identificatore e non una stringa tra apici. Per questo motivo, meglio non usare gli apici in questi casi.

// Yep
$font-type: sans-serif;

// Nope
$font-type: 'sans-serif';

// Okay I guess
$font-type: unquote('sans-serif');

// Yep
$font-type: sans-serif

// Nope
$font-type: 'sans-serif'

// Okay I guess
$font-type: unquote('sans-serif')

Possiamo fare quindi una distinzione tra le stringhe che vogliamo usare come valori CSS (vedi l’esempio qui sopra) e stringhe che si riferiscono a dati Sass, come le chiavi di una mappa.

Non usiamo gli apici nel primo caso, ma usiamo gli apici singoli nel secondo.

Stringhe che contengono apici / apostrofi

Se una stringa contiene uno o più apici singoli o apostrofi, si può considerare di utilizzare per la stringa il doppio apice ("), in modo da evitare di spezzare la stringa.

// Okay
@warn 'You can\'t do that.';

// Okay
@warn "You can't do that.";

// Okay
@warn 'You can\'t do that.'

// Okay
@warn "You can't do that."

URL

Le URL dovrebbero sempre essere tra apici, per le stesse ragioni:

// Yep
.foo {
  background-image: url('/images/kittens.jpg');
}

// Nope
.foo {
  background-image: url(/images/kittens.jpg);
}

// Yep
.foo
  background-image: url('/images/kittens.jpg')

// Nope
.foo
  background-image: url(/images/kittens.jpg)

Numeri

In Sass, i numeri sono un tipo di dato che include cifre senza unità, lunghezze, durate, frequenze, angoli e così via. Abbiamo così la possibilità di fare calcoli usando queste misure.

Zero

I numeri dovrebbero avere lo zero prima di un valore decimale inferiore a uno. Non scrivete mai zero alla fine del valore.

// Yep
.foo {
  padding: 2em;
  opacity: 0.5;
}

// Nope
.foo {
  padding: 2.0em;
  opacity: .5;
}

// Yep
.foo
  padding: 2em
  opacity: 0.5

// Nope
.foo
  padding: 2.0em
  opacity: .5

Unità di misura

Quando si ha a che fare con le lunghezze, un valore 0 non dovrebbe mai avere l’unità di misura.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

L’errore più comune che si può immaginare riguardo i numeri e Sass è pensare che le unità di misura siano solo stringhe che si possono aggiungere ai numeri. Se delle volte è vero, non è così che le unità di misura funzionano in Sass. Le unità di misura dovrebbero essere immaginate come simboli algebrici. Ad esempio, moltiplicare 5 pollici per 5 pollici ci dà 25 pollici quadrati. La stessa logica va applicata a Sass.

Per aggiungere l’unità di misura ad un numero, basta moltiplicare il numero per 1 unità.

$value: 42;

// Yep
$length: $value * 1px;

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Funziona anche aggiungere 0 di quella unità di misura, ma consiglierei il metodo precedente, dato che aggiungere 0 unità può creare confusione. Quando invece proviamo a convertire un numero in un altra unità di misura compatibile, aggiungere lo zero non serve a nulla. Per saperne di più potete leggere questo articolo.

$value: 42 + 0px;
// -> 42px

$value: 1in + 0px;
// -> 1in

$value: 0px + 1in;
// -> 96px

$value: 42 + 0px
// -> 42px

$value: 1in + 0px
// -> 1in

$value: 0px + 1in
// -> 96px

Dipende quindi da cosa si sta cercando di ottenere. C’è da ricordare che aggiungere l’unità come una stringa non è una buona maniera di procedere.

Per rimuovere l’unità di misura di un valore, basta dividere di una unità del suo genere.

$length: 42px;

// Yep
$value: $length / 1px;

// Nope
$value: str-slice($length + unquote(''), 1, 2);

$length: 42px

// Yep
$value: $length / 1px

// Nope
$value: str-slice($length + unquote(''), 1, 2)

Aggiungere un’unità di misura come stringa ad un numero genera una stringa, impendendo qualsiasi altra operazione sul valore. Anche fare uno str-slice (ovvero tagliare una parte della stringa), prendendo solo la parte numerica, genererà comunque una nuova stringa. Non è certo quel che vogliamo. Usiamo lunghezze, non stringhe.

Calcoli

I calcoli numerici dovrebbero essere sempre contenuti all’interno di parentesi tonde. Non solo così aumenterete di molto la leggibilità, ma eviterete alcuni casi limite, forzando Sass a valutare il contenuto delle parentesi prima di procedere con altri calcoli.

// Yep
.foo {
  width: (100% / 3);
}

// Nope
.foo {
  width: 100% / 3;
}

// Yep
.foo
  width: (100% / 3)

// Nope
.foo
  width: 100% / 3

Numeri magici

Il “Numero magico” è un termine da vecchia scuola della programmazione utilizzato per descrivere costanti numeriche senza nome. In pratica si tratta di un numero casuale che semplicemente funziona anche senza nessuna logica dietro.

Non ci sarebbe bisogno di dirlo ma: i numeri magici sono una piaga e dovrebbero essere evitati a qualsiasi costo. Quando non riuscite a capire perchè un numero funziona, aggiungete almeno un bel commento esaustivo, che spiega per bene come siete arrivati ad utilizzare questo numero e come mai pensate che funzioni. Ammettere che non sapete precisamente come funziona è comunque un aiuto per il prossimo sviluppatore che metterà mano al vostro codice.

/**
 * 1. Magic number. This value is the lowest I could find to align the top of
 * `.foo` with its parent. Ideally, we should fix it properly.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Magic number. This value is the lowest I could find to align the top of
 * `.foo` with its parent. Ideally, we should fix it properly.
 */
.foo
  top: 0.327em /* 1 */

Su questo argomento c’è questo magnifico articolo sui numeri magici in CSS e vi consiglio di leggerlo.

Colori

I colori occupano un importante posto nel mondo CSS. Ovviamente Sass è un nostro grande alleato quando si tratta di manipolare i colori, per lo più fornendoci una serie di potenti funzioni.

Sass è così utile quando si tratta di manipolare colori, che sono spuntati ovunque su internet articoli su questo argomento. Posso raccomandarvene alcuni da leggere:

• How to Programmatically Go From One Color to Another
• Using Sass to Build Color Palettes
• Dealing with Color Schemes in Sass

Formati di colore

Per creare colori nel modo più semplice possibile, il mio consiglo è quello di seguire questo ordine di preferenze per il formato colore:

1. Notazione HSL;
2. Notazione RGB;
3. Notazione Esadecimale (minuscolo e in versione abbreviata).

Le parole chiave CSS non dovrebbero essere utilizzate, tranne che per prototipazione fatta al volo. Inoltre sono parole in inglese e alcune di loro non descrivono perfettamente il colore che rappresentano, soprattutto per chi non è madrelingua. Oltre a questo, le parole chiave CSS non sono perfettamente semantiche; per esempio grey (grigio), è più scuro di darkgrey (grigio scuro), inoltre si può generare confusione tra grey (grigio in inglese) e gray (grigio in americano), introducendo inconsistenza nell’uso di questo colore.

La rappresentazione HSL del colore non solo è la più facile da comprendere per il cervello umano ^{[citazione necessaria]}, ma rende anche più facile sistemare i colori, manipolando separatamente la tonalità, la saturazione e la luminosità.

RGB ha il beneficio di mostrare chiaramente se il colore è più rosso, verde o blu. Per questo motivo delle volte risulta migliore dell’HSL, specialmente quando si tratta di descrivere colori primari puri. Tuttavia non rende molto semplice creare un colore mescolando le tre parti.

Infine, poniamo l’esadecimale, praticamente indecifrabile per la mente umana. Utilizzatelo solo come ultima risorsa, se proprio dovete.

// Yep
.foo {
  color: hsl(0, 100%, 50%);
}

// Also yep
.foo {
  color: rgb(255, 0, 0);
}

// Meh
.foo {
  color: #f00;
}

// Nope
.foo {
  color: #FF0000;
}

// Nope
.foo {
  color: red;
}

.foo
  color: hsl(0, 100%, 50%)

// Also yep
.foo
  color: rgb(255, 0, 0)

// Nope
.foo
  color: #f00

// Nope
.foo
  color: #FF0000

// Nope
.foo
  color: red

Quando usate la notazione HSL o RGB, aggiungete sempre un singolo spazio dopo la virgola (,) e non inserite nessuno spazio tra le parentesi tonde e il contenuto ((, )).

// Yep
.foo {
  color: rgba(0, 0, 0, 0.1);
  background: hsl(300, 100%, 100%);
}

// Nope
.foo {
  color: rgba(0,0,0,0.1);
  background: hsl( 300, 100%, 100% );
}

// Yep
.foo
  color: rgba(0, 0, 0, 0.1)
  background: hsl(300, 100%, 100%)

// Nope
.foo
  color: rgba(0,0,0,0.1)
  background: hsl( 300, 100%, 100% )

Colori e variabili

Quando usate un colore più di una volta, abbinatelo ad una variabile con un nome che serva a rappresentare il colore.

$sass-pink: hsl(330, 50%, 60%);

$sass-pink: hsl(330, 50%, 60%)

Ora potete usare questa variabile ovunque vogliate. Se il vostro utilizzo è fortemente legato ad un tema mi sento di sconsigliare l’uso di questa variabile così com’è. Associatela ad un’altra variabile che descriva come questo colore dovrebbe essere usato.

$main-theme-color: $sass-pink;

$main-theme-color: $sass-pink

Fare così vi eviterà di dover cambiare domani il tema con qualcosa del genere: $rosa-sass: blue. Questo articolo fa un ottimo lavoro nello spiegare perché è importante pensare bene al nome da dare alle vostre variabili di colore.

Schiarire e scurire i colori

Entrambe le funzioni lighten (schiarisci) e darken (scurisci) manipolano la luminosità di un colore nello spazio HSL, aggiungendo o sottraendo luminosità allo spazio colore. In pratica non sono altro che alias che si riferiscono al parametro $lightness (luminosità) della funzione adjust-color (regola colore).

In pratica, queste funzioni non danno spesso il risultato sperato. D’altra parte la funzione mix è un ottimo modo per schiarire o scurire un colore, mischiandolo con il white (bianco) o black (nero).

Il beneficio di usare mix al posto di una delle due funzioni di cui sopra è che mix è più graduale e vi consente di andare verso il nero (o il bianco) diminuendo la proporzione del colore, mentre darken e lighten hanno la tendenza a rendere il risultato direttamente nero o bianco molto velocemente.

Se non vi và di scrivere la funzione mix tutte le volte, potete creare due funzioni pronte all’uso: tint and shade (già incluse in Compass) che fanno in pratica la stessa cosa:

/// Slightly lighten a color
/// @access public
/// @param {Color} $color - color to tint
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function tint($color, $percentage) {
  @return mix(white, $color, $percentage);
}

/// Slightly darken a color
/// @access public
/// @param {Color} $color - color to shade
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function shade($color, $percentage) {
  @return mix(black, $color, $percentage);
}

/// Slightly lighten a color
/// @access public
/// @param {Color} $color - color to tint
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function tint($color, $percentage)
  @return mix($color, white, $percentage)

/// Slightly darken a color
/// @access public
/// @param {Color} $color - color to shade
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function shade($color, $percentage)
  @return mix($color, black, $percentage)

Liste

Le liste sono l’equivalente Sass degli array. Una lista, a differenza di una mappa, è una struttura piatta creata per contenere valori di ogni tipo (incluse altre liste, creando così liste annidate).

Le liste dovrebbero rispettare le seguenti linee guida:

• possono essere scritte in una o più righe a seconda dei casi;
• vanno obbligatoriamente su più linee nel caso siano troppo lunghe per stare in una riga di 80 caratteri;
• a meno che non siano usati per CSS, hanno sempre una virgola come separatore;
• sono sempre incluse in parentesi tonde;
• una virgola di chiusura solo se su più righe.

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif);

// Yep
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
);

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif;

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif;

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,);

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif)

// Nope (not supported)
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
)

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,)

Quando si aggiunge un nuovo elemento ad una lista, bisogna sempre utilizzare la API fornita. Non provate ad aggiungere nuovi elementi manualmente.

$shadows: (0 42px 13.37px hotpink);

// Yep
$shadows: append($shadows, $shadow, comma);

// Nope
$shadows: $shadows, $shadow;

$shadows: (0 42px 13.37px hotpink)

// Yep
$shadows: append($shadows, $shadow, comma)

// Nope
$shadows: $shadows, $shadow

In questo articolo, mostro un sacco di consigli e trucchi per gestire e manipolare correttamente le liste in Sass.

Mappe

Gli autori di fogli di stile possono definire con Sass delle mappe — il termine Sass per definire array associativi, hash o addirittura oggetti JavaScript. Una mappa è una struttura dati associativa composta da chiavi e valori. Entrambe le chiavi e i valori di una mappa possono essere di differenti tipi di dato, incluso il tipo mappa. Tuttavia sconsiglio di utilizzare tipi di dato complessi come chiavi di una mappa, anche solo per amore della sanità mentale.

Le mappe dovrebbero essere così scritte:

• uno spazio dopo i due punti (:);
• parentesi di apertura (() sulla stessa riga dei due punti (:);
• chiavi all’interno di apici nel caso siano stringhe (il che rappresenta il 99% dei casi);
• ogni coppia chiave/valore su una nuova riga;
• una virgola (,) alla fine di ogni coppia chiave/valore;
• una virgola di chiusura (,) inserita dopo l’ultimo elemento, in modo da rendere più facile l’aggiunta, la rimozione o il riordino di elementi;
• la parentesi di chiusura ()) deve andare su una nuova riga;
• nessuno spazio o nuova riga tra la parentesi di chiusura ()) e il punto e virgola (;).

Esempio:

// Yep
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
);

// Nope
$breakpoints: ( small: 767px, medium: 992px, large: 1200px );

// Yep
$breakpoints: ('small': 767px, 'medium': 992px, 'large': 1200px,)

// Nope
$breakpoints: ( 'small': 767px, 'medium': 992px, 'large': 1200px )

// Nope
$breakpoints: (small: 767px, medium: 992px, large: 1200px,)

// Nope (since it is not supported)
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
)

Questa funzionalità è stata a lungo desiderata e gli articoli a riguardo sono molti. Eccone qui tre di cui raccomando la lettura: Using Sass Maps, Extra Map functions in Sass, Real Sass, Real Maps.

Set di regole CSS

A questo punto non ci rimane che ripassare qualcosa che tutti sappiamo, ovvero come andrebbe scritto un set di regole CSS (almeno secondo la maggior parte delle linee guida, inclusa CSS Guidelines):

• selettori correlati sulla stessa riga; non correlati su una nuova riga;
• la graffa di apertura ({) deve essere separata dall’ultimo selettora da uno spazio;
• ogni dichiarazione deve avere una propria riga;
• uno spazio dopo i due punti (:);
• un punto e virgola di chiusura (;) alla fine di tutte le dichiarazioni;
• la graffa di chiusura (}) deve avere una proria riga;
• una nuova riga dopo la graffa di chiusura }.

Esempio:

// Yep
.foo, .foo-bar,
.baz {
  display: block;
  overflow: hidden;
  margin: 0 auto;
}

// Nope
.foo,
.foo-bar, .baz {
    display: block;
    overflow: hidden;
    margin: 0 auto }

// Yep
.foo, .foo-bar,
.baz
  display: block
  overflow: hidden
  margin: 0 auto

// Nope
.foo,
.foo-bar, .baz
    display: block
    overflow: hidden
    margin: 0 auto

In aggiunta a queste linee guida correlate al CSS, facciamo attenzione ai seguenti punti:

• le variabili locali devono essere dichiarate prima di ogni dichiarazione e devono essere separate dalle dichiarazioni da una nuova riga vuota;
• i mixin senza alcun @content devono essere inseriti prima delle dichiarazioni;
• selettori annidati vanno sempre preceduti da una riga vuota;
• mixin con un @content vanno dopo i selettori annidati;
• nessuna nuova riga prima della graffa di chiusura (}).

Esempio:

.foo, .foo-bar,
.baz {
  $length: 42em;

  @include ellipsis;
  @include size($length);
  display: block;
  overflow: hidden;
  margin: 0 auto;

  &:hover {
    color: red;
  }

  @include respond-to('small') {
    overflow: visible;
  }
}

.foo, .foo-bar,
.baz
  $length: 42em

  +ellipsis
  +size($length)
  display: block
  overflow: hidden
  margin: 0 auto

  &:hover
    color: red

  +respond-to('small')
    overflow: visible

Ordine delle dichiarazioni

Non credo ci siano molti altri argomenti oltre a come ordinare dichiarazioni CSS, che abbiano opinioni così divergenti. Ci sono due fazioni principali:

• ordine alfabetico;
• ordine di dichiarazioni in base al tipo di dichiarazione (position, display, colori, font, eccetera…).

Ci sono pro e contro per entrambi i modi. Da una parte, l’ordine alfabetico è (almeno per chi usa l’alfabeto latino) universale, quindi non ci possono essere discussioni su come ordinare una proprietà rispetto ad un’altra. Tuttavia è davvero strano per me vedere proprietà come bottom e top non una affianco all’altra. Perchè le animazioni devono essere prima delle proprietà di posizionamento? Ci sono un sacco di stranezze nell’ordinare alfabeticamente.

.foo {
  background: black;
  bottom: 0;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
  height: 100px;
  overflow: hidden;
  position: absolute;
  right: 0;
  width: 100px;
}

.foo
  background: black
  bottom: 0
  color: white
  font-weight: bold
  font-size: 1.5em
  height: 100px
  overflow: hidden
  position: absolute
  right: 0
  width: 100px

D’altro canto, ordinare le proprietà per tipo ha perfettamente senso. Tutte le dichiarazioni correlate ai font sono riunite, top e bottom sono vicine tra loro a leggere un set di regole sembra come leggere un riassunto. Ma a meno che non vi affidiate a qualche convenzione come: Idiomatic CSS, ci sarà fin troppo spazio per l’interpretazione sul come fare le cose. Dove va a finire white-space: font o display? A quale gruppo appartiene precisamente overflow? In che modo le proprietà di un gruppo devono essere ordinate (alfabeticamente, sarebbe ironico)?

.foo {
  height: 100px;
  width: 100px;
  overflow: hidden;
  position: absolute;
  bottom: 0;
  right: 0;
  background: black;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  height: 100px
  width: 100px
  overflow: hidden
  position: absolute
  bottom: 0
  right: 0
  background: black
  color: white
  font-weight: bold
  font-size: 1.5em

C’è un altro interessante metodo riguardo l’ordine delle proprietà CSS: Concentric CSS, anche questo abbastanza popolare. In pratica, Concentric CSS si basa sul box-model per definire un ordine: si parte dall’esterno e ci si muove all’interno.

.foo {
  width: 100px;
  height: 100px;
  position: absolute;
  right: 0;
  bottom: 0;
  background: black;
  overflow: hidden;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  width: 100px
  height: 100px
  position: absolute
  right: 0
  bottom: 0
  background: black
  overflow: hidden
  color: white
  font-weight: bold
  font-size: 1.5em

Io posso dirvi che non riesco a decidermi. Un sondaggio recente su CSS-Tricks si è concluso con il 45% degli sviluppatori che ordina le proprie dichiarazione secondo il tipo, il 14% in modo alfabetico. Ma c’è anche un 39% che le ordina in maniera randomica, me incluso.

Proprio per questo, non voglio imporre una scelta in queste linee guida. Scegliete quella che preferite, purchè la manteniate in modo consistente nei vostri fogli di stile (quindi il metodo random non vale).

Selettori annidati

Una particolare funzionalità, che Sass fornisce e di cui molti sviuppatori stanno abusando, è quella dei selettori annidati. Annidare i selettori offre agli autori di fogli di stile un modo per generare lunghi selettori annidando selettori più corti uno dentro l’altro.

Regola generale

Per esempio, il seguente codice Sass:

.foo {
  .bar {
    &:hover {
      color: red;
    }
  }
}

.foo
  .bar
    &:hover
      color: red

… genererà questo CSS:

.foo .bar:hover {
  color: red;
}

Allo stesso modo, a partire da Sass 3.3 è possibile utilizzare il riferimento al selettore corrente (&) per generare selettori avanzati. Ad esempio:

.foo {
  &-bar {
    color: red;
  }
}

.foo
  &-bar
    color: red

… genererà:

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Questo approccio è molto utilizzato con la convenzione BEM per generare selettori .blocco__elemento e .block--modificatore basati sul selettore originale (.blocco in questo caso).

Il problema con i selettori annidati è che rendono definitivamente il codice molto più difficile da leggere. Chi legge deve mentalmente calcolare il selettore risultante a seconda dei livelli di indentazione; non è quindi sempre ovvio quale sarà il CSS generato.

Questo diventa sempre più vero man mano che i selettori diventano più lunghi e i riferimenti al selettore corrente (&) diventano più frequenti. Ad un certo punto, il rischo di perdere traccia e di non capire più cosa sta accadendo diventa sempre più grande, tanto che annidare non vale più la pena.

Per prevenire queste situazione, abbiamo discusso a lungo qualche anno fa riguardo la regola Inception. Il suggerimento è semplice, ovvero evitare di andare oltre 3 livelli di profondità, come riferimento al film Inception di Christopher Nolan. Io sarei più drastico e raccomando di evitare i selettori annidati il più possibile.

Per quanto ci siano alcune eccezioni a questa regola, come vedremo nella prossima sezione, questa opinione pare essere molto popolare. Potete leggere a riguardo qualcosa su questi articoli: Beware of Selector Nesting e Avoid nested selectors for more modular CSS.

Eccezioni

Per iniziare: è consentito ed anche raccomandato annidare pseudo-classi e pseudo-elementi al selettore iniziale.

.foo {
  color: red;

  &:hover {
    color: green;
  }

  &::before {
    content: 'pseudo-element';
  }
}

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

Utilizzare selettori annidati per le pseudo-classi e gli pseudo-elementi non solo ha senso (perchè riguardano da vicino il selettore correlato), ma aiuta anche ad avere tutto quel che riguarda un componente nello stesso punto.

Inoltre, quando si utilizza uno stato di classe agnostico, come is-active, è totalmente corretto annidarlo sotto il selettore del componente per tenere le cose compatte.

.foo {
  // …

  &.is-active {
    font-weight: bold;
  }
}

.foo
  // …

  &.is-active
    font-weight: bold

Infine, quando si stila un elemento perchè contenuto da un altro specifico elemento, è corretto utilizzare l’annidamento per tenere tutto ciò che riguarda un componente nello stesso spazio.

.foo {
  // …

  .no-opacity & {
    display: none;
  }
}

.foo
  // …

  .no-opacity &
    display: none

Come per tutto, le specifiche sono sì rilevanti, ma è la consistenza la chiave. Se vi sentite pienamente fiduciosi di un selettore annidato, allora utilizzatelo. Solo siate sicuri che tutto il team sia d’accordo con voi.