Les classes atomiques en CSS, les avantages (le 6 décembre 2013)

Maintenant que dans le billet précédent Les classes atomiques en CSS, j’ai démonté quelques idées reçues, voyons les avantages des classes atomiques.

Design dans le navigateur

J’entends régulièrement le concept de design dans le navigateur, eh bien avec les classes atomiques, Firebug et les briques que j’ai dans RÖCSSTI, cela me permet souvent de le faire très aisément, et même – surtout – sur des sites en responsive.

Exemple : il m’arrive de devoir mettre à jour le site SEIC très rapidement (urgence, etc.). Avec les briques que j’ai dans RÖCSSTI, je construis en général très facilement ce dont j’ai besoin. Le table-layout allié aux quelques classes d’alignements font des miracles, sans pour autant détruire la structure d’un document HTML.

Plus agréable encore, cela diminue les modifications que je dois apporter à la CSS.

La CSS grossit moins, et moins vite

Je ne parle pas de l’argument légèrement fallacieux de la compression GZIP qui est améliorée (est-ce vraiment l’avantage que l’on cherche en premier ???), mais de la CSS elle-même. Voici un graphique rapidement fait qui explique bien le propos.

Le poids de la CSS grandit moins vite avec les classes atomiques

Je constate depuis plusieurs projets qu’une base bien réutilisable (donc à coups de classes atomiques)… hé bien, ça simplifie quand même bien la vie, et surtout les projets évoluent bien mieux.

Pourquoi un tel phénomène ? C’est assez simple. Dans un cas, on construit avec des mini-briques prévues pour, et dans l’autre, on a des maxi-briques, moins facilement réutilisables. Évidemment, je ne dis pas que c’est impossible de réutiliser sans les classes atomiques. C’est juste moins prévu pour. Encore une fois, les pré-processeurs aident à limiter cet aspect, mais ils le font encore mieux avec les classes atomiques.

J’avais évoqué CSS Stats, cet outil confirme bien la sensation que l’on peut avoir en tant qu’intégrateur, entre une CSS bien maintenable, et un ogre difficile à manœuvrer. Encore une fois, ce n’est qu’un outil qui donne des tendances, pas une vérité absolue. Néanmoins, il serait dommage d’ignorer ces conseils.

Des approches comme SMACSS et OOCSS se marient bien avec ce concept. Dites-vous bien que produire des CSS maintenables apporte des bénéfices à court terme, mais c’est à moyen et long termes que vous verrez une très nette différence (j’en reparlerai).

La compréhension est immédiate, même hors contexte

Sauf votre respect, le sens d’une classe, c’est très arbitraire, ou alors c’est sur un tout petit projet avec peu d’intervenants. Sur un site énorme ayant subi beaucoup de modifications, peut-être que votre bloc .bloc-news se retrouve dans les FAQ. Qui va être aussi réutilisé ailleurs. Là-dessus, le dernier développeur arrive, et ne comprend rien à la logique, qui de toute manière a disparu.

À la rigueur, il va creuser un peu, pour peu que l’intégrateur précédent ait pensé à sortir ses noms de classes des contextes, il s’en sortira un peu. Mais multipliez les intervenants, saupoudrez avec les demandes parfois contradictoires d’un client, et je peux vous assurer que la CSS qui pique les yeux, ça devient vite une réalité.

Tandis que des classes .w20 ou .aligncenter, ça cause tout de suite à un intervenant. Même s’il est nouveau, surtout s’il est nouveau.

Conclusion

C’est un véritable outil qui a de réels avantages. Et c’est un puriste élevé au grain de la classe sémantique qui tient ce discours, c’est dire. Si vous vous penchez sur des CSS maintenables, c’est un sujet incontournable.

Les sites que je maintiens et qui ont bénéficié de ces choix se portent plutôt bien. Leur CSS ne bouge quasiment plus et pourtant les mises en page évoluent. Après, comme toute approche, elle a des limites, et elle a besoin du bon sens de celui qui la manie. L’ignorer par dogmatisme serait par contre une erreur bien regrettable.

6 commentaires

Posté par Pascal le 07/12/2013 à 1:52:11

Bonjour Nicolas,

je te rejoins à 100% sur les avantages des classes "atomiques" (ou helpers ou utilities...)
Au final quel que soit le sélecteur auquel nous appliquons nos styles, on manipule bien souvent les mêmes choses : display, padding, margin... répéter ces styles un peu partout ne fait qu'alourdir les feuilles de style.

Après quelques projets pour lesquels les changements furent légion, j'en suis même arrivé à "abuser" des classes "atomiques" et à limiter la création d'objets (OOCSS) dont la dénomination ne convenait plus ou parce qu'il fallait en créer un clone (ou un modifier) pour quelques petits changements...

(l'utilisation des placeholders - partie 1 - avec préprocesseurs est à mon avis profiter des avantages de ces classes en phase de dev pour ne pas en profiter en prod... au final les styles sont répétés)

Pour éviter de surcharger les css avec des classes non utilisées, il existe des outils comme uncss https://github.com/giakki/uncss et la task grunt qui va avec https://github.com/addyosmani/grunt-uncss (avec des liens vers d'autres solutions)

Cela peut permettre de ne pas se soucier (trop) de ce que l'on inclus au départ, sachant que ce sera "néttoyé". (attention aux classes manipulées en js qui n'apparaissent pas "de base" dans le HTML : config de l'outil et/ou préfixe js-* pour ces classes)

Par rapport au RWD, j'utilise aussi une syntaxe v1- v2- ... (basée sur la syntaxe des grilles de suitcss) pour certaines règles utilisées pour certaines MQ , par exemple un texte centré sur mobile uniquement se verra appliqué le préfixe v1-textCenter, cela évite d'écraser les styles définis (je n'aime pas "farcir" mes MQ de règles qui viennent en écraser d'autres)

Ce n'est cependant pas adapté à tout le monde. Chacun a ses habitudes. Si l'ajout d'une classe "sémantique" est bien évidemment envisageable, il faut (à mon avis) éviter de s'en servir dans la CSS (les modifications se font plus dans les templates HTML...)
Il faut faire son choix (quel qu'il soit) et s'y tenir sans (trop) mélanger les genres.

à ce sujet, http://adactio.com/journal/6537/ :

[] if you’re going to write an article about the right way to do something, don’t start by labelling dissenting schools of thought as dogmatic or purist

Posté par Vincent le 07/12/2013 à 18:01:43

Hello Nico,

Vous allez finir par me convaincre à force de répéter les bienfaits de cette technique !

Il me reste cependant deux interrogations fortes :

1. la séparation de la forme et du contenu qui tend à disparaitre ;
2. la complexité du code HTML qui augmente au profit de la complexité du code CSS qui diminue.

Sur le premier point, n’y a t-il pas un problème quand on réalise un site responsif par exemple ? Une classe `.aligncenter` pourrait par exemple se voir affublée d’un `text-align: center` en desktop, d’un `text-align: left` en mobile, et d’un `text-align: right` en tablette. Ou est la cohérence ?

Pascale évoque une solution dans son commentaire en préfixant (ou en suffixant) les classes par une information relative au média ou au contexte d’affichage.

Pour autant, `<div class="w20-xs w40s w60m w80l"></div>` ne me semble ni maintenable, ni extensible, ni léger.

— Que ce passe t-il si je souhaite modifier une largeur ; dois-je retoucher à tout mes fichiers HTML là où je ne modifiait jusque là que la feuille de style ?
— Comment puis-je ajouter un nouveau contexte media facilement ?
— Ne risque t-on pas dans certains cas complexes à fortement surcharger les pages HTML, là où CSS proposait une factorisation des styles ?

Sur le second point, c’est une réflexion que je me fais au regard de mon cycle de production en agence. Il arrive bien souvent qu'un gap existe entre le code HTML statique que je produis et le code dynamique qui est ensuite réalisé en développement (et ce pour de multiples raisons).

En plaçant au maximum (toute raison gardée) la complexité du code côté CSS, je m'assure un HTML le plus léger possible, très lisible et donc peu source d’erreurs ou d’ajustements nécessaires.

C'est (il me semble) le sens vers lequel évolue le langage CSS en proposant des pseudos-classes puissantes, qui viennent épurer le code HTML.

Lorsque le HTML se voit affublé de multiples classes, je ne peux m’empêcher de craindre de nombreux aller/retours supplémentaires, suite à de nouvelles impossibilités (bien souvent à mettre au compte des CMS).

Que penses-tu/pensez-vous de ma réflexion ? Où fais-je fausse route ?

Merci en tout cas pour tes deux billets : ils me font mieux prendre conscience des avantages de la technique ; je regrette même de l’avoir boudée jusque là par certains aspects !

Posté par nicod_ le 07/12/2013 à 19:54:36

Merci pour ces deux article.
En pleine remise en question de mes méthodes d’intégration, c'est une bonne source d'inspiration.

Je n’avais pas accroché sur l’approche oocss au début à cause du trop grand nombre de classes nécessaires pour créer des héritages corrects dans le html, et de la dépendance que ça créait.
Mais je m’intéresse sérieusement à sass et je découvre des possibilités qui changent complètement mon appréciation, notamment grâce à des articles comme celui ci sur les placeholders (encore mieux que les extend) :
http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way

Posté par Nico le 08/12/2013 à 0:09:24

Vincent : effectivement, selon le cas de figure, tu peux être amené à déplacer la complexité sur le HTML ou sur la CSS. En général, je constate que j'ai plus d'avantages à éviter de revenir dans la CSS plutôt que dans le code HTML : cela évite d'augmenter trop le poids de la CSS (je dirais même d'une CSS en production).

Un point important : les classes atomiques ne me servent en général que sur le contenu, moins sur les gabarits de base (header, etc.).

J'ai plutôt rarement le genre de cas que tu montres ici : genre un bloc qui fait 80% sur desktop, 30% sur tablette, etc. En général, c'est plus simple. Idem pour les alignements.

Curieusement, c'est en lâchant prise sur certains aspects que j'ai trouvé le plus de simplicité : typiquement, les classes .m1, .p1, .pr1 etc. sont super pratiques : travailler intégralement en em même pour les padding/margin offre tellement d'avantages, de facto je sais que les espacements sont fonction de la police, et donc le zoom fonctionne. Par exemple

Et côté performances, je constate que mes dernières intés sont beaucoup plus rapides, tant sur le point du poids de la CSS que sur la rapidité du rendu. Je compare toujours les perfs avec les mêmes options, j'arrive à des sites qui se chargent vraiment vite, genre des first load à moins de 3 secondes (fully-loaded). Comme sur http://www.pnlcoach.com/ qui descend même parfois en-dessous de 2s.

Les autres classes sont là aussi pour permettre à ces bouchers de devs back (

) de pouvoir styler au besoin sans faire trop de dégâts. Typiquement, le table layout sur RÖCSSTI me simplifie vraiment la vie.

Par contre, pour ma part, faisant souvent le front et le back (une sorte de front-end first

), j'évite autant que possible ce gap dont tu parles. Il m'est arrivé de triturer des menus de CMS jusqu'à la moelle pour leur faire cracher ce que je veux. Les CMS que j'utilise permettent en général de respecter à la lettre l'intégration... manquerait plus que ça, sans blague !

Si je n'ai qu'un conseil : il faut essayer, et utiliser avec raison. Ce n'est pas la solution ultime (ça serait malhonnête de dire ça), mais ça aide bien sur certains aspects.

Posté par Gaël le 09/12/2013 à 12:29:53

Excellent(s) article(s) Nicolas !

Je pratique aussi les classes atomiques, avec parcimonie comme tu le conseilles. Les classes d’espacement sont un réel plaisir à utiliser, et j’ajouterais à leurs avantages qu’on respecte bien plus facilement un rythme vertical quand les espacements sont prédéfinis (en tout cas, dans mon contexte d’utilisation - à savoir des thèmes WordPress la plupart du temps - leur utilisation est très bénéfique pour la mise en place structurelle et la cohérence finale).

La remarque de Vincent sur la séparation du fond et de la forme me fait réfléchir : c’est presque utopique, non ? Dans un contexte RWD, on a vite tendance à afficher ou masquer des blocs (changement de fond) et les éléments HTML ayant une forme intrinsèque, il me semble extrêmement compliqué aujourd’hui de conserver cette séparation.

En revanche, si un article a des marges d’un em pour des raisons graphiques, il y a de fortes chances qu’il doive conserver cet espacement dans tous les contextes afin de rester homogène. La séparation du fond et de la forme semble ténue, désormais…

Mais effectivement ce sont des questions à se poser.

Pour reprendre l’exemple de l’alignement de texte donné par Vincent, ça me semble être précisément une mauvaise utilisation d’une classe «atomique» : le changement d’alignement selon le contexte correspond à une «division» du format de l’élément. Nous ne sommes donc plus en présence d’atome, puisque l’élément va être divisé.

Voilà une règle à mémoriser : une classe atomique ne devrait être utilisée que quand elle n’aura pas à être modifiée (elle doit donc être appliquée dans tous les contextes).

À l’inverse, un élément dont l’alignement varie selon le contexte devrait disposer d’une classe «sémantique» spécifique à lui et aux modules similaires (une molécule, non ?).

C’est une théorie déjà exprimée ici :
http://bradfrostweb.com/blog/post/atomic-web-design/
et qui semble s’éclaircir après ces deux articles.

Merci Nicolas !!

Posté par Kaelig le 16/12/2013 à 10:18:41

Merci Nico pour ce rappel.

@Vincent : Un HTML complexe est rarement un souci tant que les éléments sont bien utilisés et la sémantique est relativement correcte. Il est de plus en plus rare d'arriver sur un projet où on se dit "ce code HTML est vraiment mauvais !". Par contre sur quasiment tous les projets la CSS a moisi au fur et à mesure des itérations, et c'est le bordel. D'où l'intérêt de déporter une part de la complexité d'un langage à l'autre (CSS vers HTML) pour créer des systèmes qui grandissent élégemment.

Le saviez-tu : à chaque fois que l'on code un joli module avec un nom spécifique (donc non réutilisable) et des sélecteurs parfaits par amour du HTML "propre", on ouvre une faille spatio-temporelle par laquelle le collègue qui devra maintenir ce code peut revenir pour nous botter le derrière à tout moment.

Les classes atomiques en CSS, les avantages