Lutte des classes CSS !

Les classes CSS sont probablement le meilleur ami de l’intégrateur web, mais peuvent vite devenir un cauchemar si la réflexion ne précède pas l’action. Au-delà des conventions de nommage plus ou moins sémantiques, il existe de nombreuses stratégies pour mettre en place une architecture CSS modulable et évolutive. Un temps décriées au profit des identifiants uniques pour de viles questions de performances, les classes reprennent du poil de la bête. Sans forcément tomber dans la «classite» aiguë, voyons rapidement différentes manières d’organiser nos feuilles de style CSS.

Exemple 1

Exemple de code permettant d’appliquer un style commun aux éléments commençant par .btn- et de décliner des styles spécifiques pour .btn-left ou .btn-right. Larry Botha dans About HTML semantics and front-end architecture.

[class*="btn-"] { } // Styles génériques
.btn-small { }      // Diminuer font-size
.btn-medium { }     // Taille par défaut
.btn-large { }      // Augmenter font-size
.btn-primary { }    // Faire flotter le bouton à gauche
.btn-secondary { }  // Faire flotter le bouton à droite
.btn-left { }       // Ajouter une icône à gauche des boutons
.btn-right { }      // Ajouter une icône à droite des boutons

Exemple 2

On peut aussi s’inspirer du modèle d’architecture de l’exemple précédent en jouant sur les classes multiples :

.btn { }            // Styles génériques pour les boutons
.icon-right { }     // Ajouter une icône à droite de n'importe quel élément
.icon-left { }      // Ajouter une icône à gauche de n'importe quel élément
.btn.icon-right { } // Ajouter une icône à droite du bouton
.btn.icon-left { }  // Ajouter une icône à gauche du bouton

Exemple 3

Autre manière d’application d’un style générique à un élément .item déclinable selon le contexte. Rapide et pratique, cette solution présente tout de même l’inconvénient de ne pas être totalement scalable si vous décider de créer un nouveau contexte tel que #header .item {}

.item {}             // styles génétiques pour item
#cart .item { }     // styles spécifiques pour item dans le contexte du panier
#category .item { } // styles spécifiques pour item dans le contexte des catégories
#product .item { }  // styles spécifiques pour item dans le contexte des produits

Pour rendre ce dernier exemple plus scalable et plus performant (en évitant d’obliger le navigateur de boucler sur trop de sélecteurs), on pourrait utiliser :

.item { }
.item-cart {  }
.item-category { }
.item-product { }

L’approche des classes multiples est moins performante mais permet de modulariser votre feuille de style de manière plus fine. A condition toutefois d’en avoir vraiment besoin. En effet, leur utilisation se traduit forcément par une intrusion accrue des classes CSS dans le code HTML et nécessite plus de règles dans la feuille de style, ce qui peut manquer de… classe !

.item { }
.cart { }
.category { }
.product { }
.item.cart {  }
.item.category { }
.item.product { }

Pour aller plus loin

• Organiser ses classes CSS — Comment ça, il n’existe pas de consensus sur l’organisation des feuilles de style CSS ?
• SMACSS — Scalable and Modular Architecture for CSS. A flexible guide to developing sites small and large. (cf. SMACSS — Architecture évolutive et modulaire pour CSS
• About HTML semantics and front-end architecture  — Covers HTML semantics, components and approaches to front-end architecture, class naming patterns, and HTTP compression.
• Writing efficient CSS selectors — The difference in speed between an ID and a class is almost totally irrelevant.