Les id et les classes

Le balisage des documents HTML offre de nombreuses possibilités pour les styler. Bien entendu, il est possible de cibler des blocs ou des éléments directement par leur balise, toutefois, cette approche – qui était quasi-systématique avant – a tendance à se raréfier.

On cible effectivement certains éléments directement par leur balise pour des « resets » CSS ou des balises dont la sémantique est en quelque sorte « auto-suffisante ». Mais il est actuellement plus souvent coutume de cibler les éléments par les classes.

Même si le ciblage par id est toujours possible dans la feuille de style (faire ainsi n’empêchera pas de faire fonctionner un site, ce n’est pas une erreur en soi), il est désormais réservé à des cas vraiment très particuliers et/ou fortement déconseillé pour de nombreuses raisons :

• Il est difficile d’avoir la garantie qu’un élément restera unique tout le long de la vie du site. Autrement dit, ils sont souvent trop couplés à la structure HTML, qui elle peut beaucoup évoluer.
• Leur définition même les rend impossibles à réutiliser : par principe ils sont uniques.
• Leur fort poids [1] rend difficile la surcharge, par exemple une classe ajoutée à l’élément stylé via un id ne pourra pas surcharger les styles de cet id. Cela a souvent amené à utiliser !important en dépit du bon sens ou à avoir des sélecteurs qui s’allongent ou se complexifient inutilement (genre #element.classe).

Par contre, si les id sont beaucoup moins utilisés pour cibler des éléments en CSS voire plus utilisés du tout, cela ne veut pas dire qu’il faille les bannir des structures HTML, bien au contraire ! (ne serait-ce que pour avoir des ancres internes à la page, entre autres nombreuses utilisations [2])

Du plus général au plus spécifique

Que l’approche retenue soit de type desktop-first ou mobile-first, la CSS doit toujours partir des règles les plus générales de l’approche choisie pour aller vers les plus spécifiques. Ainsi, cela garantira :

• de couvrir le plus de cas possibles avec les règles générales ;
• d’éviter de définir de nombreux styles trop spécifiques là où un style plus général aurait permis de les économiser ;
• de permettre une surcharge aussi légère que possible.

Ce principe s’exprime via plusieurs aspects :

• l’ordre et la structure de votre CSS (par exemple, le reset est en premier car ce sont les propriétés les plus générales qui soient, elles doivent être exécutées avant toutes les autres) ;
• la spécificité de vos sélecteurs CSS : les plus spécifiques priment sur les plus généraux ;
• la factorisation élégante de propriétés CSS ;
• les propriétés de l’agent utilisateur : si votre site utilise par exemple des media-queries, les propriétés de ces dernières doivent pouvoir surcharger et/ou s’appliquer sans nécessiter des sélecteurs à rallonge.

Il sera donc capital d’ordonner la feuille de style très rigoureusement.

Certaines raisons peuvent rendre difficile l’application de ce principe, par exemple sur un projet nécessitant de très nombreux développeurs n’ayant parfois aucune communication possible entre eux (équipe éclatée), il sera important de veiller à ce que les styles spécifiques ne s’entrechoquent pas (en posant des conventions en amont par exemple).

N.B : ce principe peut également s’exprimer selon le mode d’inclusion des styles CSS, par exemple, les styles en ligne sont prioritaires par rapport à des styles inclus dans la page via une balise <style>, lesquels sont également prioritaires sur une feuille de style externe. Toutefois, comme il est en général souhaitable d’inclure les styles dans un fichier externe pour d’évidentes raisons de maintenabilité, nous nous en tiendrons à l’inclusion de styles par fichier [3].

Séparation structure/présentation autant que possible

Un des autres grands principes de l’intégration est de permettre la séparation entre la structure (HTML) et la présentation (CSS). Toutefois, vous aurez noté dans le titre que nous avons ajouté « autant que possible » en emphase.

Ne nous voilons pas la face : si la séparation structure/présentation était un principe absolu il y a quelques années, l’appliquer à l’extrême a posé bon nombre de problèmes [4]. Même si la sémantique des classes est possible et parfois souhaitable, ne le cachons pas : les classes sont souvent là uniquement pour permettre de styler un site, plus rarement pour réellement permettre à un document d’être sémantiquement communicant.

Actuellement, ce principe est toujours valable, il s’exprime juste de manière différente qu’auparavant sur la manière d’intégrer. Ainsi, il sera de bon ton d’éviter de rendre la CSS trop dépendante à une structure HTML donnée (qui peut fortement évoluer et prendre la CSS en défaut). Par exemple :

• on préférera cibler un élément directement via une classe (.module-titre) plutôt que via le conteneur allié à une balise (.module h3) ;
• sauf cas particulier, des sélecteurs trop spécifiques comme p.ma-classe seront à bannir, on leur préfèrera .ma-classe ;
• etc.

Les classes sémantiques

Faisons un aparté sur le sujet des classes sémantiques. De nombreux débats parfois enflammés font rage sur le sujet des classes sémantiques, c’est-à-dire l’emploi de classes censées renseigner ou étendre le sens de ce qu’elles contiennent [5]).

Il n’est pas dans l’intention de cet article de réécrire l’histoire. Le seul objectif est d’observer l’évolution de la pratique. Ajoutons à cela qu’attacher des classes sémantiques à un élément est totalement possible en intégration moderne, tout comme il est tout à fait possible d’utiliser des classes non-sémantiques… en somme, comme c’est à la fois possible de le faire ou de ne pas le faire, cette question est tout simplement non pertinente dans le cadre de cette série d’articles – et dans ce cadre uniquement.

Références, compléments

• CSS, l’âge de raison
• Un HTML avec class et des id

Note

Cet article fait partie de la série « Grands principes de construction moderne de CSS ».