8 règles pour organiser son code CSS

mis à jour le 10 mars 2021

Rédiger du code CSS n’est pas aussi simple qu’il n’y paraît. Sans quelques règles de rédaction, on peut se retrouver rapidement avec un code compliqué à lire et difficile à debugger. Voici une liste non exhaustive de bonnes pratiques et règles qui vous aidera à créer et maintenir une feuille de style CSS claire et extensible.

1 – Segmenter le CSS en fichiers multiples

Il est préférable de séparer son code CSS en plusieurs fichiers chacun correspondant à un module, une vue ou une page de votre application. À vous de choisir comment découper votre feuille de style. Le découpage en fichiers permet de s’y retrouver plus facilement lorsqu’il faut étendre, modifier ou créer de nouvelles déclarations.
Par exemple, pour WordPress, il peut être judicieux de découper votre code par modèle de contenu.

  • page.css
  • single.css
  • header.css
  • footer.css
  • archive.css
  • template-custompage.css

L’intérêt de découper le CSS en fichiers multiples et décupler surtout si vous utilisez un préprocesseur CSS (Sass ou Less).

2 – Établir une convention de Nommage

Il est primordial de disposer d’une convention de nommage de vos éléments.
Si dans votre application il y a un bloc qui contient une navigation secondaire, vous pouvez lui donner une classe qui s’appellera « .secondary-nav » ou « .nav-secondary » ou « .navSecondary » ou « .Nav_Secondary ».
Il existe bien des recommandations sur quelle est la meilleure façon de nommer ces blocs, mais je ne vous donnerai pas de recommandations, il faut simplement choisir une norme et s’y tenir pour l’ensemble de l’application. Cependant si vous choisissez de respecter la méthodologie BEM, alors certains des exemples cités ci-dessus seront à éviter.

3 – Utiliser BEM (Bloc, Element, Modifier)

BEM est une méthodologie de nommage qui tend à découper les entités de votre page en blocs et éléments.
Pour faire simple Une page peut contenir plusieurs blocs, chacun de ces blocs peuvent contenir un ou plusieurs éléments qui lui sont propres. Enfin chacun de ces éléments peut avoir un état qui est modifié selon un événement ou action de l’utilisateur, c’est le modifier.

Par exemple, une page web est composée de 4 blocs :

  • Navigation
  • Main Content
  • Side Bar
  • Footer

La side bar est composé de différents éléments :

  • Titre
  • Liste des derniers articles
  • Liste des derniers commentaires

L’élément « Liste des derniers articles » peut avoir plusieurs états :

  • Cacher
  • Visible

Nous venons de découper notre page selon la méthodologie BEM appliquée au CSS.

4 – Utiliser le CSS Orienté Objet (OOCSS)

Il s’agit de découper les classes en tentant de respecter la logique du développement orienté objet que l’on rencontre dans des langages de programmation comme le PHP.

Prenons l’exemple d’un bouton rouge et vert :

.boutonRouge {
    display: block;
    font-size: 12px;
    color: red;
    border: 1px solid red;
}

.boutonVert {
    display: block;
    font-size: 12px;
    color: red;
    border: 1px solid red;
}


Dans ces deux exemples, il y a une répétition de code, on va plutôt essayer de regrouper les propriétés que ces boutons partagent. Puis créer une classe supplémentaires correspondant à leurs spécificités respectives.

.bouton {
    display: block;
    font-size: 12px;
    border-width: 1px;
    border-style: solid;
    border-color: transparent;
}
.bouton-rouge {
    border-color: red;
    color: red;
}
.bouton-vert {
    border-color: green;
    color: green;
}

En HTML, le bouton sera appelé comme suit :

<div class="bouton bouton-rouge">Bouton rouge</div>


On fait cohabiter les classes côte à côte. L’intérêt est de conserver une consistance de base pour tous les éléments boutons, on les surcharge au besoin avec une classe supplémentaire qui vient étendre les propriétés du bouton, dans notre cas on rajoute une couleur de bordure et une couleur de texte.

5 – Comprendre le Principe Open/Close

Ce principe va de paire avec l’exemple aborder dans le point précédent.
Lorsque l’on choisit une approche OOCSS, il faut toujours se remémorer ce principe assez simple :
– Le code CSS doit être extensible (ouvert à toute extension) mais non modifiable (fermé à toute modification).
En reprenant l’exemple du bouton :

.bouton {
    display: block;
    font-size: 12px;
    border-width: 1px;
    border-style: solid;
    border-color: transparent;
}


Et que je crée une classe pour un bouton secondaire :

.bouton-secondaire {
    display: inline-block;
    font-size: 10px;
    border-width: 0;
    border-style: none;
}


HTML :

<div class="bouton bouton-secondaire">Bouton secondaire</div>


On constate que la classe .bouton-secondaire vient modifier les propriétés display, font-size et border-width de la classe bouton. On perd donc l’intérêt de l’extension car on vient modifier et non pas étendre des propriétés. Il aurait été plus simple de créer une nouvelle classe .bouton-secondaire en enlevant les déclarations relatives aux bordures (border-width et border-style) et d’utiliser cette classe de façon autonome.

6 – Prendre en compte la portabilité et sélecteurs quasi-qualifiés

La portabilité permet de réduire la dépendance de nos classes à des balises HTML par exemple. Prenons un exemple simple :

a.bouton { }


La classe bouton est déclarée mais uniquement utilisable avec une balise <a>. Si on veut utiliser la classe bouton avec une balise <div>, ce n’est plus possible.
Il faut donc retirer la référence à la balise HTML. Si on veut aider à la lecture du code et explicité que la classe bouton est à utiliser préférablement avec une balise <a> alors on pourrait rédiger la classe comme suit :

/*a*/.bouton { }


La balise est passé en commentaire mais elle est utilisable sur toute type de balise. C’est ce qu’on appelle un sélecteur quasi-qualifié.

7 – Comprendre la spécificité

La spécificité détermine quelle règle CSS est appliquée par le navigateur. Il y a une hiérarchie pas forcément intuitive dans l’ordre d’application des règles CSS.

Il faut garder en tête que tout sélecteur doit être déclarer avec le moins de spécificité possible.
Préférer :

.myclass { }


Plutôt que :

body.page .content .sidebar > .myclass { }


Ceci vous évitera dans la plupart des cas de faire face à des conflits liés à la spécificité CSS.

Imbrication ou Nesting (en anglais)

L’imbrication des classes CSS a été introduite par les langages tels que Sass et Less.
L’imbrication a des avantages évidents lorsque l’on rédige le code mais génère un code CSS parfois trop spécifique (voir point précédent).
Il faut tenter d’avoir le minimum d’imbrications. Moins il y a de sélecteurs, mieux c’est. Ainsi on aura moins de mauvaises surprises.

8 – Être DRY

Il s’agit d’un principe qui vise à réduire la quantité de code écrit et de regrouper les déclarations en doublon.
Il faut l’appliquer si deux déclarations cohabitent très souvent ensemble. Le principe DRY peut-être très utile lorsque l’on code en Less ou Sass.

Exemple :

.texte-erreur {
    font-size: 15px;
    background-color: #ccc;
    border-color: red;
    color: red;
}
.bloc-erreur {
    width: 250px;
    height: 250px;
    background-color: #000;
    font-size: 17px;
    border-color: red;
    color: red;
}


On constate que les deux classes partagent les propriétés border-color et color. On peut considérer qu’elles se retrouvent toujours ensemble pour un certain nombre de classes. Alors on peut créer un mixin et les classes suivants :

@mixin erreur-base() {
border-color: red;
color: red;
}
.texte-erreur {
font-size: 15px;
background-color: #ccc;
@include erreur-base();
}
.bloc-erreur {
width: 250px;
height: 250px;
background-color: #000;
font-size: 17px;
@include erreur-base();
}


On a gagné en lisibilité et refactorisé notre code pour éviter des répétitions.

Conclusion

Voici un ensemble de bonnes pratiques qui permettent de poser des bases solides à la rédaction d’un code CSS lisible et extensible.
Tous les projets ne se prêtent pas forcément à ce type de règles. Par exemple lorsqu’il est nécessaire de styliser un thème WordPress et un plugin comme WooCommerce, les règles de nommage CSS ne sont pas forcément homogènes et il peut être difficile d’instaurer ces bonnes pratiques.

Ce billet a été en très grande partie inspirée du très pertinent guidelin.es qui aborde davantage de points. Comme toujours libre à vous de les suivre et de les adapter à vos projets.

Si vous souhaitez approfondir vos connaissances en CSS, je vous recommande cette liste de ressources, sites, comptes twitter & livres CSS.