|<- [[IDs in CSS]]|[[!important]] ->|

====== Nesting ======

Nous avons déjà vu comment le nichage peut amener à une dépendance à la localisation et à du code potentiellement inefficace, mais il est temps de regarder à un autre de ses problèmes : il rend les sélecteurs plus spécifiques.

Lorsque l'on parle de nichage, on ne parle pas nécessairement de nichage préprocesseur, tel que :

<code>
.foo {

  .bar { }

}
</code>

Nous parlons en réalité de sélecteurs descendants ou enfants; des sélecteurs qui concrnent un élément dans un élément. Cela peut ressembler à n'importe lequel des suivants :

<code>
/**
 * An element with a class of `.bar` anywhere inside an element with a class of
 * `.foo`.
 */
.foo .bar { }


/**
 * An element with a class of `.module-title` directly inside an element with a
 * class of `.module`.
 */
.module > .module-title { }


/**
 * Any `li` element anywhere inside a `ul` element anywhere inside a `nav`
 * element
 */
nav ul li { }
</code>

Que vous arriviez à ce résultat avec des préprocesseurs CSS ou non n'est pas important, mais cela vaut le coup de remarquer que les préprocesseurs vendent cela comme une fonctionnalité alors que cela devrait être évité autant que possible.

Pour parler de manière générale, chaque partie d'une sélecteur ajoute de la spécifité. Par conséquent, moins un sélecteur comportera de parties, moins sa spécificité sera grande, et l'on souhaite en toute circonstance garder la spécificité basse. Pour citer Jonathan Snook:

> …quel que soit le moment où vous déclarez des styles, utilisez le moins possibles des sélecteurs pour styler un élément.

Regardons un exemple :

<code>
.widget {
  padding: 10px;
}

  .widget > .widget__title {
    color: red;
  }
</code>

Pour styler un élément avec la classe .widget[[__]]title, nous avons un sélecteur deux fois plus spécifique que nécessaire. Cela signifie que si nous souhaitons faire des modifications à .widget[[__]]title, nous aurons besoin d'un autre sélecteur au moins aussi spécifique :

<code>
.widget { ... }

  .widget > .widget__title { ... }

  .widget > .widget__title--sub {
    color: blue;
  }
</code>

Non seulement cela est totalement évitable — nous avons nous même causé le problème — mais nous avons un sélecteur qui a littéralement deux fois la spécificité dont il a besoin. Nous avons utilisé 200% de la spécificité nécéssaire. Et ça n'est pas que cela, mais cela amène aussi une verbosité accrue de notre code —more to send over the wire.

Pour règle, si un sélecteur peut fonctionner sans être niché, ne le nichez pas.

===== Scope =====

Un des possibles avantages du nichage — qui malheureusement ne suffit pas à contrebalancer les désavantages d'une spécificité augmentée — est qu'il fourni une sorte de namespace. Un sélecteur comme .widget .title confine la portée d'un élément de stylage de.title à un élément qui n'existe qu'à l'intérieur d'un élément portant la classe .widget.

This goes some way to providing our CSS with scope and encapsulation, mais signifie toujours que nos sélecteurs sont deux fois plus spécifiques que nécéssaire. Une meilleure manière de fournir une portée serait par un namespace — dont nous disposons déjà en la présence du nommage BEM-like —qui n'engendre pas une augmentation inutile de la spécificité.

Nous avons maintenant un CSS avec une meilleure portée et une spécificité minimum — le meilleur des deux mondes.

==== Further Reading ====

  - [[http://csswizardry.com/2013/05/scope-in-css/|‘Scope’ in CSS]]