Au début était la Pangée. Un magma informe, une soupe de balises où se noient des styles épars et obscurs. Tout cela dans un ensemble de code inextricable et bien difficile à comprendre et maintenir !
Et l'on se rendit compte que HTML et CSS étaient tout autant faciles à écrire qu'extrêmement complexes à maintenir, et que seuls certain•e•s sorcier•e•s étaient capable d'assurer une consistence à leurs incantations codes source.
Les premières méthodologies CSS "grand public" voient le jour dans les années 2008-2009 sous l'impulsion, entre autre, de Nicole Sullivan alors ingénieure chez Facebook qui évoque le terme de "CSS Orienté Objet" ou "OOCSS" notamment lors d'une conférence à Paris-Web.
Méthodologies, Frameworks, Preprocesseurs
À l'instar de véritables langages de programmation, CSS se voit s'articuler autour de lui différentes approches, méthodologies et frameworks.
- Les Approches et méthodologies CSS définissent généralement des règles de nommage ou des bonnes pratiques à suivre.
Les plus utilisées à ce jour sont : OOCSS (Nicole Sullivan), BEM (Yandex), SMACSS (Jonathan Snook), Atomic CSS (Yahoo!) et ITCSS (Harry Roberts) - Les Frameworks CSS : désignent des environnements d'intégration complets et généralement fondés sur l'une des méthodologies sus-citées.
On y trouve par exemple : Bootstrap (historiquement Twitter), Foundation (Zurb), Materialize CSS (Google), Tailwind (Adam Wathan), Bulma (Jeremy Thomas), Tachyons (John Otander) et PureCSS (Yahoo!). Sans oublier KNACSS (Alsacréations) bien sûr ! - Les Pré et post-processeurs : sont des outils permettant de générer ou d'améliorer du code CSS existant. Les plus célèbres étant postCSS (Evil Martians), Sass, LESS et Stylus.
Si l'ensemble de ces approches et outils existent et prospèrent de nos jours, c'est bien parce qu'ils se sont fait leur place dans la réalité des environnements de production.
Comme disaient les cssribes de l'antiquité : "il n'y a pas de bonne ou de mauvaise approche" car :
- Les méthodologies répondent à des besoins
- Les méthodologies évoluent (car les besoins évoluent)
"Être consistant au sein d'une grosse équipe", "Ne pas avoir besoin de toucher au CSS", "Ne pas avoir besoin de comprendre CSS"… sont tout autant de besoins qui peuvent être légitimes.
Certains frameworks, dont Bulma, se targuent d'ailleurs de ne nécessiter aucune compétence en CSS (si cela vous choque… c'est que vous n'en n'avez sans doute pas besoin).
On veut des chiffres !
Si vous aimez les graphiques et les chiffres, sachez que le site web "State of CSS" suit de près les tendances de ce langage :
- État des lieux des méthodologies CSS en 2019
- État des lieux des méthodologies CSS en 2020
- Évolution des frameworks CSS en 2020 (notez les taux de satisfaction, d'intérêt et d'appropriation des différents frameworks)
- Évolution des pré-post processeurs CSS en 2020
L'histoire des approches CSS de IE4 la préhistoire à nos jours
Approche (pré)Historique
La belle époque des <font>, des <center>, des <b>, mais aussi des tableaux de mise en forme à grand renfort de rowspan, colspan et autres valign a longtemps bercé notre enfance d'intégratrice et intégrateur. Les supports navigateurs et les bugs en tout genre complétèrent le tableau (huhu) d'un pseudo-langage bancal qu'était CSS.
Exemple
<div class="center"></div>
<font>
<center>
<b> <!-- j'ai mal rien que d'écrire tout ça --></b>
</center>
</font>
Avantages et inconvénients
Un avantage indéniable est que le terme "center" est parfaitement compréhensible pour un être humain, même un développeur web.
Par contre, un élément <center>, ou un <div class="center">, véhiculent des notions purement graphiques, or HTML ne devrait transmettre que des informations de contenu, être dénué de notions de style. En mélangeant allègrement les deux, on complique le rôle et diminue l'intérêt de chacun.
Si cet élément change de style selon le contexte (n'est plus centré sur un grand écran par exemple), le choix de classe devient totalement incohérent. C'est problématique.
Approche Sémantique
Mettons vite le hola à ces pratiques barbares et revenons aux bases que sont :
- le HTML c'est pour la structure et le contenu (le fond)
- le CSS c'est pour la présentation (la forme)
Exemple de sémantique
<div class="container">
<div class="author-info">
<h2>Francis Lalanne</h2>
<img src="" alt="" />
<p class="author-desc">Un troubadour des temps anciens.</p>
</div>
</div>
.author-bio {
...;
}
.author-bio > h2 {
...;
}
.author-bio > img {
...;
}
.author-bio > .author-desc {
...;
}
Avantages et inconvénients
Grâce à ces classes "sémantiques", mon code HTML est propre et pourvu de sens et de logique, et surtout je comprends bien quelle est la fonction de chaque élément (enfin, normalement).
Alors par contre c'est drôle mais cela devient assez vite compliqué de trouver des noms de classe cohérents (salut à toi .modal-wrapper > .inner-content > .warning-global!).
Avouez que "Nommer les choses en CSS est compliqué" et que depuis l'ère du Responsive et des CSS modernes ça ne va pas en s'arrangeant car il faut aujourd'hui non seulement trouver des noms de classes, mais aussi de variables CSS, de valeurs de Breakpoints, etc.
Fort heureusement, tout le monde utilise de solides Conventions de nommage CSS de nos jours, n'est-il pas ?
En creusant bien, je me heurte à une autre problématique : comme souhaité, mon HTML n'a plus de notions de styles… mais maintenant c'est CSS qui est devenu très dépendant de ma structure HTML car les noms de classes ne contiennent plus aucune information graphique. Je dois systématiquement vérifier mon CSS pour deviner à quoi va ressembler ma classe .warning. Au final, j'ai simplement retourné la situation, et je n'ai pas séparé HTML de CSS.
Méthodologie BEM
La méthodologie "BEM" (pour "Block Element Modifier") a été élaborée par le moteur de recherche russe Yandex. Elle trouve racine en 2010 mais s'est vraiment activement développée à partir de 2015. Son objectif est de faciliter la réutilisation de composants CSS et d'assurer une cohérence de nommage à travers les équipes et dans la durée.
BEM impose une règle de nommage différente que selon que l'élément soit un "Block" (entité autonome), un "Element" (dépendant d'un Block) ou un "Modifier" (variante de Block ou d'Element).
Trois règles distinguent BEM d'autres approches :
- Tous les éléments HTML doivent chacun avoir un nom sous forme de
classCSS (pas de nommage viaid) - Les sélecteurs CSS ne doivent cibler que des classes (pas d'élément tel que
nav, nia, niuldans le nom d'un sélecteur par exemple) - Les sélecteurs CSS composés / hiérarchiques sont à éviter (pas de
.menu .list, ou de.navigation > a)
Exemple de BEM
<div class="container">
<div class="author-info">
<h2 class="author-info__title">Francis Lalanne</h2>
<img class="author-info__image" src="" alt="" />
<p class="author-info__desc">Un troubadour des temps anciens.</p>
</div>
</div>
.author-bio {
...;
}
.author-bio__title {
...;
}
.author-bio__image {
...;
}
.author-bio__desc {
...;
}
Avantages et inconvénients
La méthodologie BEM évite toute surprise : sa convention de nommage très stricte permet à coup sûr de comprendre à quoi sert chaque élément mais aussi de choisir le bon nommage quand j'en crée un nouveau. Je comprends ce que mes collègues écrivent et je comprends ce que j'ai moi-même écrit il y a 6 mois dans mon projet.
En outre, la structure HTML peut changer sans aucun impact sur le style (car CSS ne cible que des classes et non des balises HTML).
Enfin, il devient extrêmement facile de maintenir, modifier voire écraser des styles existants puisqu'il n'y a qu'un seul niveau de poids : un sélecteur CSS = une classe unique.
Mais il y a forcément des contreparties…
Mon code HTML a subitement doublé de taille, car chacun des éléments de structure (même s'il n'est pas utilisé) doit avoir un nom de classe à lui, voire plusieurs s'il dispose de variantes.
Et surtout, comment gérer efficacement tous les composants très similaires graphiquement mais dont la fonction est différente (ex. un .article__preview qui serait quasi identique à un .author__info) ?
Au final, pour résoudre cette problématique, on ajoutera généralement un niveau d'abstraction plus vaste ("content-agnostic") tel que .card ou .btn ou .badge. Et forcément, la précision et la compréhension en prennent un sale coup.
Approche Atomique
L'approche Atomique (ou "utilitaire") trouve ses origines en octobre 2013 au sein d'un article de Thierry Koblenz sur Smashingmagazine. Cet article donne naissance à ACSS qui est adopté par Yahoo! dès 2015.
Les principes essentiels de cette approche sont :
- À chaque classe CSS correspond une seule fonction (ex.
.txt-left {text-align: left}ou.mr-2 {margin-right: 2rem}) - Le styles CSS sont volontairement dénués de contexte (agnostiques) pour être totalement indépendants de la structure HTML
- Les sélecteurs CSS composés n’existent pas (pas de
.menu .list, ou de.navigation > a) - Il n'est plus nécessaire d'intervenir dans la feuille de styles CSS. Plus aucun CSS à écrire, modifier ou maintenir car le fichier CSS existe initialement ou est généré au fur et à mesure.
Exemple d'approche atomique
<div class="container md:grid grid-col-3 bg-hotpink p-10 mb-6">
<div class="text-center md:text-left">
<h2 class="text-lg bg-chocolate rounded-full">Francis Lalanne</h2>
<img class="h-16 w-16 md:h-24:w-24" src="" alt="" />
<p class="p-10 my-6 hover:bg-orange">Un troubadour des temps anciens.</p>
</div>
</div>
.text-center {
...;
}
.text-left {
...;
}
.text-lg {
...;
}
.p-10 {
...;
}
Avantages et inconvénients
Atomic CSS, on l'adore ou on le déteste, mais quoi qu'il en soit il est impossible de se tromper dans le nommage ! Il n'y a aucune surprise ni de pièges, personne ne se torture l'esprit ni ne peut bifurquer puisque le nommage existe déjà. Toutes les classes CSS vous attendent, inutile d'en créer davantage.
De plus, je n'ai même plus besoin de fouiller dans mes fichiers CSS, tout se passe côté HTML et je peux me concentrer sur un seul langage lors de mon intégration.
Se fonder sur un nombre de classes existant et restreint m'impose une cohérence (difficile d'avoir 150 niveaux de gris différents par exemple, même si c'est possible.)
Enfin, les contextes d'affichage tels que le Responsive peuvent parfaitement être pris en charge.
Mais encore une fois il y a forcément des contreparties et elles sont de taille
- Ça pique carrément les yeux ! C'est moche. C'est un fait.
- Mon HTML est alourdi, difficile à lire, et contient partout de multiples classes
- Mon CSS, s'il doit prévoir toutes les classes utilitaires dans tous les contextes possibles, aura une taille gigantesque.
- Contrairement aux apparences, j'ai besoin de très bien connaître CSS et toutes ses propriétés pour en déduire toutes les classes utilitaires (oh mais attendez, connaître les CSS n'est pas censé être un inconvénient n'est-ce pas ?)
Mais alors c'est quoi la meilleure méthodologie ?
Pour la petite anecdote, je me souviens très bien du jour où j'ai découvert CSSLint et son incitation à "ne pas utiliser de sélecteur d'ID en CSS". Ma première réaction fut de vivement réfuter en block cet argument car la "Bonne Pratique" de l'époque était de cibler les éléments uniques de la page via des #id, et CSSLint allait clairement à l'encontre de toutes nos années d'apprentissage et d'usage de CSS.
J'ai mis quelques années à changer d'avis.
Cet exemple, parmi tant d'autres, démontre qu'une bonne pratique n'est pas figée dans le temps.
Des projets différents impliquent des besoins différents et une approche différente. Tout cela pour conclure qu'aucune approche n'est meilleure qu'une autre car certaines sont parfaitement adaptées à des typologies de projets particuliers, ou aux compétences de l'équipe. Et d'autres non.
Le mot de la fin revient à Thierry Koblenz, ancien chef des experts CSS chez Yahoo!, "inventeur" des CSS atomiques :
Pour Yahoo!, ACSS s’est révélé être un super outil mais si je devais refaire mon site perso demain ce serait certainement 80% sémantique et 20% atomique > (« utility classes »).
Et pour une page toute bête, je pense que ça frôlerait les 99.99% (sémantique ou atomique selon l’humeur du moment).
Source : Thierry Koblenz, 2016
Finalement, vous l'aurez compris, cet article n'avait pas pour but de vous imposer un choix de méthodologie mais plutôt de vous rendre attentif aux avantages et inconvénients de chacune.
N'hésitez pas à enrichir ce débat en avouant votre amour inconditionnel pour Atomic CSS ou votre haine sans fin pour BEM, nous faire découvrir d'autres approches modernes, ou simplement nous témoigner de celle(s) que vous adoptez dans vos projets.