Architecture CSS et nomenclature selon les méthodologies

Si vous avez déjà développé un site, il y a fort à parier que la question de la nomenclature et architecture CSS vous ait déjà passé par la tête. Depuis le temps que je développe, je peux vous assurez que certaines approches sont meilleures que d’autres. Si aucune des méthodologies n’est parfaite, elles peuvent certainement apporter des solutions. Je vous propose de faire, ou refaire, le tour des tendances en la matière.

Architecture CSS et nomenclature

« OOCSS »

L’idée fondamentale veut qu’en ramenant le tout à des class plûtôt que des id, on peut récupérer les propriétés de .skin à d’autres endroits dans l’application. Ça peut sembler évident aujourd’hui mais cette façon de faire était assez novatrice il y a quelques années.

Séparation de la structure et de l’apparence

Par exemple, l’objet media est nommé avec class="media", et ses composantes avec class="img" (pour la composante « image/video ») class="bd" (pour la composante « body/text »).

Séparation du contenu et du contenant

Un objet devrait garder son apparence peu importe où vous le placez. Par exemple, au lieu de définir un h2, on lui assigne une classe et c’est celle-ci qu’on définie.

#button {
  width: 200px;
  height: 50px;
  padding: 10px;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#box {
  width: 400px;
  overflow: hidden;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#widget {
  width: 500px;
  min-height: 200px;
  overflow: auto;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

Les trois éléments ci-dessus sont définis par des id et ont des styles uniques et d’autres en commun.
On peut donc extraire tout ce qui est commun dans une nouvelle class comme ceci :

.button {
  width: 200px;
  height: 50px;
}

.box {
  width: 400px;
  overflow: hidden;
}

.widget {
  width: 500px;
  min-height: 200px;
  overflow: auto;
}

.skin {
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

« BEM »

L’idée fondamentale de BEM est d’utiliser les class multiples à même le code HTML pour permettre au développeur une lecture et une compréhension adéquate.

Créer une relation entre le HTML et le CSS

La convention BEM aide les développeurs web à mieux comprendre la relation entre HTML et CSS

Augmenter la confiance des développeurs

En comprenant la relation entre les blocs, éléments et modificateurs, les développeurs peuvent mieux anticiper les conséquences d’un changement par la simple lecture du code HTML et/ou CSS.

/* Composante principale ou bloc */
.btn {}

/* Éléments dépendants du bloc */ 
.btn__text {}
.btn__price {}

/* Modificateurs qui changent l'apparence de l'élément */
.btn--big {}
.btn--orange {}

<a class="btn btn--big btn--orange" href="/">
  <span class="btn__text">Ajouter cet article à</span>
  <span class="btn__price">9,99 $</span>
</a>

« SMACSS »

L’idée fondamentale de SMACSS est de catégoriser les choses comme elles sont, partout dans le code comme étant « Base », « Layout », « Module », « State » ou des « Themes ».

Améliorer la sémantique

En adoptant la méthode, SMACSS augmente la valeur sémantique d’une section de contenu HTML.

Écrire un meilleur CSS

SMACSS est plus un guide qu’un cadre restrictif, un ensemble de tutoriels sur la façon d’écrire un bon CSS.

/* Styles de base */
html,
body,
form {
  margin: 0;
  padding: 0;
}

input[type=text] {
  border: 1px solid #999;
}

a {
  color: #039;
}

a:hover {
  color: #03C;
}

/* Module "Example" */
.example {}

/* Module "Callout" */
.callout {}

/* État */
.is-collapsed {}

/* Module "Callout" avec état */
.callout.is-collapsed {}

/* "Layout" "Inline" */
.l-inline {}

Les autres

En plus des trois méthodes précédentes, d’autres existent pour organiser votre architecture CSS. Voici une liste à titre de référence, vous trouverez de l’information à propos de chacun sur les articles ou page des projets suivants :

• MaintainableCSS
• Atomic CSS
• MCSS
• AMCSS
• FUN
• SUIT CSS
• RSCSS

Quelle méthode utiliser?

Utilisez la méthodologie avec laquelle vous vous sentez le plus à l’aise, ou mélangez-les en prenant les meilleures parties de chacune. Même si ce n’est pas obligatoire, je conseille toujours d’adopter une architecture CSS, même pour les petits sites. En ce qui concerne les sites de plus grandes envergures, il sera important d’y réfléchir au début du développement car le code source deviendra impossible à maintenir à court, moyen et long terme. Par expérience, j’ai vu des milliers de lignes de code en trop dans des fichiers ici et là, causant un tord irréparable au développement futur des applications.

Si vous avez besoin d’aide pour mettre en place les meilleures pratiques au sein de votre équipe, n’hésitez pas à communiquer avec nous.

Ressources externes :

• Bradley, Steven, « An Introduction To SMACSS Guidelines For Writing CSS », 19 mars 2012.
• Walton, Philip, « CSS Architecture », 16 novembre 2012.
• Hiljá Studio, « OOCSS, ACSS, BEM, SMACSS: what are they? What should I use? », 23 janvier 2014.
• Danylko, Jonathan, « 5 Methodologies for Architecting CSS », 9 janvier 2017.