Une si mauvaise ID ?

De plus en plus de ressources web nous encouragent à ne plus utiliser de sélecteur d’id en CSS, par exemple : « Our best practises are killing us », CSSLint et sa documentation, « Don’t use id selectors in CSS ». Etc.

Cette règle qu’on nous assène est forcément dérangeante, puisqu’elle peut paraître illogique et va à l’encontre de toutes nos années d’apprentissage et d’usage de CSS.

Quelques explications

Le sélecteur d’id (ex. #kiwi) et le sélecteur de classe (ex. .kiwi) ont été tous deux introduits en CSS1 afin de cibler les éléments HTML et de leur appliquer des styles.

Leur différence fondamentale est que « l’id c’est pour les éléments uniques, et les classes c’est pour les éléments multiples ».

Nous avons donc tous été bercé par la routine suivante : dès qu’un élément est unique (header, footer, navigation, barre latérale, etc.), on l’affuble d’un attribut id et on le cible en CSS à l’aide de cet id.

Il faut cependant parfois accepter de se remettre en question et de se rendre compte qu’il y a une autre énorme critère qui les différencie : leur spécificité.

En effet, le poids d’un sélecteur d’id sera toujours plus fort que celui d’une classe, voire de centaine de classes. Or en production, si l’on souhaite disposer de styles et CSS efficaces et réutilisables, cette surcharge pondérale de l’id est un réel handicap.

Exemple concret

L’exemple suivant permet très facilement et très vite de comprendre le soucis de spécificité de l’id.

Au cours d’une de mes formations CSS, je propose à mes élèves de cibler et modifier les comportements de liens d’une liste lors du survol et du focus au clavier.

La structure initiale est la suivante :

<ul id ="first">
<li><a href="#">Accueil</a></li>
<li><a href="#">Société</a></li>
<li><a href="#">Contact</a></li>
</ul>

<ul id ="second">
    <li><a href="#">Accueil</a></li>
    <li><a href="#">Société</a></li>
    <li><a href="#">Contact</a></li>
</ul>

La couleur de fond des liens au départ est rose ou orange :

#first a {background: pink}
#second a {background: orange;}

Puis je demande simplement de modifier la couleur au survol et au focus.

Fort logiquement, et en raison du poids du sélecteur id, la syntaxe suivante est inopérante :

a:hover, a:focus {
    background: tomato;
}

Pour s’assurer de disposer de suffisamment de poids, il est nécessaire de donner autant de poids qu’un id, et la syntaxe s’alourdit subitement :

#first a:hover, #first a:focus, 
#second a:hover, #second a:focus {
    background: tomato;
}

Imaginez si mon sélecteur initial avait été plus lourd encore, comme div ul#first li a{} !

L’autre alternative est d’employer le bazooka !important, mais je préfère ne pas en arriver là.

La conclusion est que si la structure de départ avait été différente, avec un choix de classe et non d’id, la mission aurait été largement facilitée :

<ul class="first">
<li><a href="#">Accueil</a></li>
<li><a href="#">Société</a></li>
<li><a href="#">Contact</a></li>
</ul>

<ul class="second">
    <li><a href="#">Accueil</a></li>
    <li><a href="#">Société</a></li>
    <li><a href="#">Contact</a></li>
</ul>

et la syntaxe suivante fonctionne puisque les pseudo-classes :hover et :focus ont le même poids qu’une classe :

a:hover, a:focus {
}

Gardez quelques bonnes ID de côté

Dans le cadre d’intégration en production, ou avec des frameworks CSS, il est essentiel de bénéficier de styles réutilisables et donc d’éviter autant que possible toute spécificité (donc des attributs id). Dans presque tous les cas, un id peut avantageusement être remplacé par une classe… même si l’élément semble unique.

Attention toutefois à ne pas verser dans l’excès inverse, les id ne doivent pas être totalement bannis pour au-moins quelques raisons :

  • ils sont souvent nécessaires pour cibler des élément via JavaScript,
  • ils demeurent plus performants que d’autres sélecteurs (mais de l’ordre de la milliseconde)
  • ils ont un rôle, celui d’identifier les éléments uniques (même s’il ne faut jamais  présumer de ses “éléments uniques” : une sidebar unique a vite fait d’avoir une soeur au cours de l’évolution d’un projet)
  • ils sont indispensables pour créer des ancres dans la page, ou des liens d’évitements pratiques pour l’accessibilité de vos documents.

Et vous, quelle est votre relation avec les id ?