Sass Guidelines

Syntaxe & formatage

À mon avis, la première chose que devrait proposer un guide de style est de décrire la façon dont notre code doit être écrit, du point vue de son aspect.

Lorsque plusieurs développeurs sont impliqués dans l’écriture de CSS sur un même projet, il ne faut pas longtemps avant que l’un d’entre eux commence à faire les choses à sa façon. Les directives servent à éviter cette perte de cohérence, mais aussi à aider chacun à lire et à mettre à jour le code.

Globalement, voici ce que nous voulons (inspiré sans honte des CSS Guidelines) :

• Une indentation à deux (2) espaces, pas de tabulation ;
• Pas plus de 80 caractères par ligne ;
• Du CSS écrit sur plusieurs lignes ;
• Une utilisation efficace des lignes vides.

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

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

    padding: 0 1em;
}

// Quant à Sass, sa syntaxe indentée impose ces standards de codification
// Il n’y a donc pas de "mauvaise" manière de procéder
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Chaînes de caractères

Ça peut paraître incroyable, mais les chaînes de caractères jouent un grand rôle dans les écosystèmes CSS et Sass. La plupart des valeurs CSS sont soit des longueurs soit des identifiants, il est donc crucial de se tenir à des règles lorsqu’on utilise ces chaînes dans Sass.

Encodage

Afin d’éviter tout problème potentiel lié à l’encodage des caractères, il est recommandé de forcer l’encodage UTF-8 dans le fichier principal en utilisant la directive @charset. Assurez-vous que ce soit le premier élément de la feuille de style et qu’il n’y ait aucun caractère de quelque nature en amont.

@charset 'utf-8';

@charset 'utf-8'

Guillemets

En CSS, les chaînes de caractères n’ont pas à être entourées de guillemets, pas même celles qui contiennent des espaces. Prenez les noms de font-family par exemple : peu importe qu’elles soient ou non entre guillemets.

C’est pourquoi dans Sass les chaînes de caractères n’ont pas non plus à être entourées de guillemets. Mieux, (et heureusement) une chaîne de caractères entre guillemets est strictement équivalente à sa jumelle sans guillemets (p.ex. 'abc' est strictement égale à abc).

Ceci étant, les langages qui ne requièrent pas d’envelopper les chaînes de caractères entre guillemets sont une infime minorité, c’est la raison pour laquelle les chaînes de caractères devraient toujours être entourées de guillemets simples (') dans Sass (pourquoi des guillemets simples ? parce qu’ils sont plus faciles à taper sur un clavier qwerty). À part la cohérence avec d’autres langages, dont JavaScript le cousin de CSS, il y a plusieurs raisons à ce choix :

• les noms de couleurs sont traités comme des couleurs lorsqu’ils ne sont pas entre guillemets, ce qui peut conduire à de sérieux problèmes ;
• la plupart des colorations syntaxiques fonctionnent mieux avec les guillemets ;
• la lisibilité est améliorée ;
• il n’y a pas de raison valable de ne pas utiliser de guillemets.

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Chaînes comme valeurs CSS

Certaines valeurs spécifiques de CSS (identifiants), telles que initial ou sans-serif ne doivent pas être entourées de guillemets. Si vous déclarez font-family: 'sans-serif' CSS ignorera votre déclaration car il attend un identifiant et non une chaîne de caractères. C’est pourquoi on ne met jamais de guillemets autour de ces valeurs.

// 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')

Il convient de faire une distinction entre les chaînes de caractères qui sont des valeurs CSS (il s’agit d’identifiants CSS) comme dans l’exemple qui précède, et les chaînes de caractères correspondant à des types de données Sass (par exemple les clés des maps).

On ne met pas de guillemets pour les premières, mais il en faut pour ces dernières.

Chaînes contenant des guillemets

Si une chaîne de caractères contient un ou plusieurs guillemets simples, on peut éviter l’utilisation d’échappements répétés en enveloppant la chaîne à l’intérieur de guillemets doubles (") .

// 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."

URLs

Les URL doivent être écrites entre guillemets pour les mêmes raisons que ci-dessus :

// 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)

Nombres

Dans Sass, un nombre est une donnée qui peut avoir une unité ou pas et qui décrit une longueur, une durée, une fréquence, un angle, etc. Cela permet d’effectuer des calculs sur les mesures.

Zéros

Une valeur décimale inférieure à 1 doit être précédée d’un zéro. N’écrivez pas de zéros finaux après le point.

// 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és

S’agissant de longueurs, une valeur égale à 0 ne doit pas être suivie de son unité.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

L’erreur la plus courante en ce qui concerne les nombres dans Sass est de penser que les unités sont de simples chaînes de caractères qu’on peut accoler à un nombre sans problème. Même si cela semble vrai, ce n’est pas ainsi que les unités fonctionnent. On peut voir les unités comme des symboles algébriques. Par exemple, dans le monde réel, si on multiplie 5 mètres par 5 mètres, on obtient 25 mètres carrés. La même logique s’applique à Sass.

Pour ajouter une unité à un nombre, vous devez multiplier ce nombre par 1 unité.

$value: 42;

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

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Remarquez qu’en ajoutant 0 membre de cette unité on obtient le même résultat, mais je recommande la méthode indiquée ci-dessus car l’ajout de 0 unité peut créer une certaine confusion. En effet, si vous essayez de convertir un nombre dans une autre unité compatible, ajouter 0 ne fonctionnera pas. Davantage d’information à ce sujet dans cet article sur CSS-Tricks.

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

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

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

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

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

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

En fin de compte, tout dépend de ce que vous cherchez à obtenir. Rappelez-vous simplement qu’ajouter l’unité sous forme de chaîne de caractères n’est pas la bonne méthode. Utilisez des longueurs, pas des chaînes de caractères.

Pour supprimer l’unité d’une valeur, il suffit de la diviser par une fois son unité.

$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)

Si vous ajoutez une unité sous forme de chaîne de caractères à un nombre, le résultat est une chaîne de caractères, ce qui vous empêche d’effectuer toute opération sur la valeur. De même avec l’opération slice si vous découpez la partie numérique d’un nombre — ce qui n’est sans doute pas le résultat souhaité.

Calculs

Les calculs numériques de premier niveau devraient toujours être entre parenthèses. Non seulement la lisibilité s’en trouve considérablement améliorée, mais les éventuels cas borderline sont résolus en forçant Sass à évaluer le contenu entre parenthèses.

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

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

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

// Nope
.foo
  width: 100% / 3

Nombres magiques

L’expression “nombre magique” est un vieux terme de programmation qui désigne une constante numérique non nommée. Quelque chose comme un nombre aléatoire qui fonctionne sans que l’on sache dire exactement pourquoi.

Est-il utile de préciser que les nombres magiques sont une plaie et doivent être évités à tout prix ? Si vous ne pouvez pas expliquer logiquement la raison pour laquelle un nombre fonctionne, ajoutez un commentaire détaillant la façon dont vous êtes arrivé à ce nombre et pourquoi vous pensez qu’il est approprié. Il vaut mieux expliquer pourquoi vous ne comprenez pas comment quelque chose fonctionne que de laisser au développeur qui vous suivra le soin de comprendre les raisons de votre choix.

/**
 * 1. Nombre magique. Cette valeur est la plus basse que j’ai trouvée pour aligner le haut de
 * `.foo` avec celui de son parent. Il faut trouver une solution pour faire ça proprement.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Nombre magique. Cette valeur est la plus basse que j’ai trouvée pour aligner le haut de
 * `.foo` avec celui de son parent. Il faut trouver une solution pour faire ça proprement.
 */
.foo
  top: 0.327em /* 1 */

À ce sujet, CSS-Tricks a un superbe article à propos des nombres magiques en CSS, que je vous recommande de lire.

Couleurs

Les couleurs occupent une place importante dans le langage CSS. Naturellement, Sass devient un excellent allié lorsqu’il s’agit de manipuler les couleurs, essentiellement à l’aide de quelques fonctions puissantes.

Sass est si utile quand il s’agit de manipuler les couleurs que des articles sont apparus de toute part pour en parler. Permettez-moi de vous recommander quelques lectures :

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

Formats de couleurs

Pour simplifier les couleurs autant que possible, mon conseil est de respecter l’ordre de préférence suivant pour les formats :

1. Notation HSL;
2. Notation RGB;
3. Notation hexadécimale (en minuscules et en version raccourcie lorsque c’est possible).

Les mots-clés de couleur ne devraient pas être utilisés, sauf quand il s’agit de prototypage rapide. En effet, ils sont en anglais et certains d’entre eux font un bien piètre travail quand il s’agit d’exprimer la couleur qu’ils représentent, surtout pour des personnes dont l’anglais n’est pas la langue maternelle. De plus, les mots-clés n’ont pas vraiment de valeur sémantique. Par exemple, grey se trouve être plus foncé que darkgrey, et la confusion entre grey et gray peut engendrer une utilisation incohérente de cette couleur.

La représentation HSL n’est pas seulement la plus facile à appréhender pour le cerveau humain ^{[citation requise]}, elle rend aussi les modifications de couleurs plus simples en permettant d’ajuster la teinte, la saturation et la valeur de manière individuelle.

Le format RGB a également l’avantage d’indiquer du premier coup d’oeil si la couleur est plutôt bleue, verte ou rouge. C’est pourquoi il peut être plus approprié que le format HSL dans certains cas, surtout quand il s’agit de décrire un pur rouge, vert ou bleu. Cependant, ce format rend la construction d’une couleur via ses trois composantes difficile.

Enfin, l’hexadécimal est presque indéchiffrable pour le cerveau humain. Ne l’utilisez qu’en dernier recours, si vous en avez besoin.

// 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

Si vous utilisez la notation HSL ou RGB, ajoutez toujours un espace après la virgule, mais n’ajoutez pas d’espace entre les parenthèses et le contenu.

// 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% )

Couleurs et variables

Si vous utilisez une couleur plusieurs fois, enregistrez-la dans une variable portant un nom représentatif de la couleur.

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

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

Vous pouvez maintenant utiliser cette variable où vous voulez. Cependant, si son usage est lié à un thème, je vous conseille de ne pas utiliser la variable directement mais plutôt de l’enregistrer elle-même dans une autre variable dont le nom explique la fonction.

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

$main-theme-color: $sass-pink

De cette façon vous éviterez qu’une modification de votre thème ne conduise à quelque chose comme $sass-pink: blue. Cet article explique bien pourquoi il est important de bien nommer ses variables.

Éclaircir et obscurcir les couleurs

Les fonctions lighten et darken manipulent la luminosité d’une couleur dans l’espace HSL en augmentant ou en diminuant sa valeur. En fait, elles ne sont rien d’autre que des alias du paramètre $lightness de la fonction adjust-color.

Toutefois, il arrive souvent que ces fonctions ne produisent pas le résultat escompté. La fonction mix est une autre façon d’éclaircir une couleur en la mélangeant à du blanc ou à du noir.

L’avantage d’utiliser mix plutôt que les deux fonctions précédemment citées est qu’elle permet d’aller très progressivement vers le noir (ou vers le blanc) à mesure que l’on diminue la proportion de la couleur initiale, alors que darken et lighten font passer très rapidement la couleur au noir ou au blanc :

Si vous ne voulez pas écrire la fonction mix à chaque fois, vous pouvez créer deux fonctions faciles à utiliser, tint et shade (qui sont incluses dans Compass) pour obtenir la même chose :

/// 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)

Listes

Les listes sont l’équivalent des arrays (tables) dans Sass. Une liste est une structure de données plate (contrairement à maps) dont le but est de stocker des valeurs de tout type (y compris des listes, ce qui autorise l’imbrication de listes).

Les listes doivent respecter les recommandations suivantes :

• sur une ligne ou sur plusieurs lignes ;
• impérativement sur plusieurs lignes si elles comptent plus de 80 caractères ;
• toujours utiliser une virgule pour séparer les éléments de la liste, sauf si elle est utilisée pour un contenu CSS ;
• toujours entre parenthèses ;
• ajouter une virgule après le dernier élément de la liste si elle compte plusieurs lignes.

// 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,)

Lorsque vous ajoutez de nouveaux items à une liste, utilisez toujours l’API fournie. N’essayez pas de les ajouter manuellement.

$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

Dans cet article, je parcours un certain nombre de trucs et astuces pour comprendre et manipuler les listes en Sass.

Maps

Avec Sass, les auteurs de feuilles de styles peuvent définir des maps, qui sont l’équivalent en Sass des tableaux associatifs (ou dictionnaires ou tables d’association), des hashs ou même des objets JavaScript. Une map est une structure de données qui associe des clés (keys) à des valeurs. Les clés comme les valeurs peuvent être de tout type, y compris de type map même si je ne recommanderais pas l’utilisation de types complexes comme clés, ne serait-ce que dans un souci de simplicité.

Les maps doivent être écrites comme suit :

• un espace après les deux-points (:) ;
• parenthèse ouvrante (() sur la même ligne que les deux-points (:) ;
• clés entre guillemets si ce sont des chaînes de caractères (soit 99% des cas) ;
• chaque paire clé/valeur sur sa propre ligne ;
• virgule (,) à la fin de chaque clé/valeur ;
• virgule finale (,) après le dernier item pour faciliter l’ajout, la suppression ou la réorganisation d’items ;
• parenthèse fermante ()) sur sa propre ligne ;
• pas d’espace ni de retour à la ligne entre la parenthèse finale et le point-virgule final.

Illustration :

// 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,
)

Les écrits à propos des maps sont légions tant cette fonctionnalité était attendue. En voici 3 que je recommande : Using Sass Maps, Extra Map functions in Sass, Real Sass, Real Maps.

Ensemble de règles CSS

Ici nous allons réviser ce que tout le monde sait, mais voici comment on devrait écrire une règle CSS (du moins selon la plupart des recommandations, dont CSS Guidelines) :

• les sélecteurs liés sur la même ligne, sinon sur une ligne différente ;
• l’accolade ouvrante ({) sur la ligne du dernier sélecteur séparé de celui-ci par un espace ;
• chaque déclaration sur une même ligne ;
• un espace après les deux-points (:) ;
• toujours un point-virgule (;) à la dernière déclaration d’une règle ;
• l’accolade fermante (}) sur sa propre ligne ;
• une nouvelle ligne après l’accolade fermante.

Illustration:

// 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

En plus de ces recommandations liées à CSS, nous devons être attentifs aux points suivants :

• les variables locales doivent être déclarées avant toute autre déclaration, puis séparées des autres par une ligne ;
• les inclusions de mixins sans @content doivent venir avant toute déclaration ;
• les sélecteurs imbriqués doivent toujours apparaître sur une nouvelle ligne ;
• les inclusions de mixins avec @content doivent apparaître après les sélecteurs imbriqués ;
• pas de saut de ligne avant une accolade fermante (}).

Illustration:

.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

Ordre des déclarations

Je ne connais aucun autre sujet où les opinions sont aussi partagées qu’en ce qui concerne l’ordre des déclarations CSS. Concrètement, deux opinions s’opposent :

• s’en tenir à l’ordre alphabétique ;
• classer les déclarations par type (position, display, color, font, autres…).

Il y a du pour et du contre dans chacune. D’un côté, l’ordre alphabétique est universel (du moins pour les langues utilisant l’alphabet latin), donc il n’y a pas de dispute possible quant à la position d’un sélecteur par rapport à un autre. Cependant, il me paraît bizarre de ne pas avoir des propriétés telles que bottom et top l’une derrière l’autre. Pourquoi les animations devraient-elles apparaître avant le type de display ? L’ordre alphabétique crée de nombreuses bizarreries.

.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’un autre côté, ordonner par propriété semble parfaitement logique. Les déclarations de font sont regroupées, top et bottom sont réunis et la lecture d’une règle CSS ressemble à une petite histoire. Mais à moins de s’en tenir à des conventions comme Idiomatic CSS, cette façon de faire laisse encore beaucoup de place à l’interprétation. Où situer white-space ? font ou display ? Où situer overflow ? Et quel ordre donner aux propriétés à l’intérieur d’un groupe ? (alphabétique ?… ô ironie…).

.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

Il existe encore un autre modèle d’ordonnancement des types, Concentric CSS, qui semble assez populaire lui aussi. Concentric CSS s’appuie sur le modèle de boîte pour définir l’ordre : il part de l’extérieur pour aller vers l’intérieur.

.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

Je dois dire que je n’arrive pas à me décider moi-même. Un récent sondage de CSS-Tricks a montré que plus de 45% des développeurs ordonnent leurs déclarations par type, contre 14% par ordre alphabétique. 39% le font au hasard, et j’en fais partie.

C’est la raison pour laquelle je ne recommande pas de choix particulier dans ce guide de style. Choisisssez celui que vous préférez, du moment qu’il reste cohérent tout au long de vos feuilles de style (en d’autres termes : pas l’option au hasard).

Imbrication des sélecteurs

Parmi les fonctionnalités offertes par Sass, l’une d’entre elles est souvent mal utilisée, c’est l’imbrication des sélecteurs. Celle-ci permet aux auteurs de feuilles de styles de créer de longs sélecteurs en imbriquant des sélecteurs plus courts les uns dans les autres.

Règle générale

Par exemple, l’imbrication Sass suivante :

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

.foo
  .bar
    &:hover
      color: red

… génèrera ce CSS :

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

En suivant la même idée, il est possible depuis Sass 3.3 d’utiliser la référence au sélecteur courant (&) pour générer des sélecteurs avancés, par exemple :

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

.foo
  &-bar
    color: red

… génèrera ce CSS :

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Cette méthode est souvent utilisée avec les conventions de nommage BEM pour générer des sélecteurs .block__element et .block--modifier à partir du sélecteur d’origine (.block dans ce cas).

Le problème avec l’imbrication des sélecteurs est qu’elle rend le code plus difficile à lire. On doit reconstituer mentalement le sélecteur qui en résulte à partir des niveaux d’indentation. Il n’est pas toujours évident de se représenter ce que donnera le CSS final.

C’est d’autant plus vrai à mesure que les sélecteurs s’allongent et que les références au sélecteur courant (&) se multiplient. À un certain point, le risque de confusion devient tellement élevé que l’imbrication n’en vaut pas la peine.

Pour éviter de telles situations, nous évitons l’imbrication des sélecteurs autant que possible. Il y a cependant quelques exceptions à cette règle.

Pour éviter de telles situations, il existe la fameuse Règle d’Inception (The Inception Rule) depuis quelques années. Celle-ci déconseille d’imbriquer au-delà de 3 niveaux, en référence au film Inception de Christopher Nolan. Je suis plus drastique encore et vais jusqu’à déconseiller l’imbrication des sélecteurs autant que faire se peut.

Bien qu’il y ait bien évidemment quelques exceptions à cette règle comme nous allons le voir dans la prochaine section, cette opinion tranchée semble malgré tout assez populaire. Vous pouvez en lire davantage dans Beware of Selector Nesting et Avoid nested selectors for more modular CSS.

Exceptions

Pour commencer, il est permis — et même recommandé — d’imbriquer les pseudo-classes et les pseudo-éléments à l’intérieur du sélecteur initial.

.foo {
  color: red;

  &:hover {
    color: green;
  }

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

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

Non seulement l’imbrication des pseudo-classes et pseudo-éléments est parfaitement justifiée (parce qu’il s’agit de sélecteurs étroitement liés) mais aussi elle permet de conserver tout ce qui concerne un même composant au même endroit.

De plus, lorsqu’on utilise des classes décrivant un état indépendant du composant telles que .is-active, il est tout à fait justifié de les imbriquer dans le sélecteur du composant de façon à avoir un code bien ordonné.

.foo {
  // …

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

.foo
  // …

  &.is-active
    font-weight: bold

Last but not least, lorsqu’on applique un style à un élément parce qu’il se trouve être contenu dans un autre élément spécifique, il est également logique de l’imbriquer afin que tout ce qui concerne cet élément soit réuni au même endroit.

.foo {
  // …

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

.foo
  // …

  .no-opacity &
    display: none

Comme pour toute chose, ce qui compte ce ne sont pas les détails mais la cohérence globale. Si vous vous sentez en confiance avec l’imbrication des sélecteurs, utilisez-la. Assurez-vous que toute l’équipe soit d’accord avec cette façon de faire.