Les classes atomiques en CSS

Les classes atomiques en CSS (le 06/12/2013)

Si l’on reprend la définition du mot atome, on obtient le mot grec atomos : « qui ne peut être divisé ». Appliqué aux CSS, cela revient à dire que la classe ne contient que le minimum, autrement dit une seule propriété.

Si j’ai eu l’envie d’écrire deux autres billets là-dessus, c’est tout simplement pour démonter les propos que j’entends habituellement sur ce sujet, et qui sont souvent… à côté de la plaque.

Un atome ?

Ce concept, bien qu’utilisé largement avant, a été bien débattu sur cet article Challenging CSS Best Practices et en dehors sur d’autres sites. Le sujet est régulièrement abordé, et l’atelier que j’ai co-présenté à Paris-Web cette année n’y a pas échappé.

Petite revue non exhaustive de ce que j’entends à ce sujet.

J’ai l’impression de faire des styles en ligne

Ok, on peut avoir l’impression, et j’insiste sur le mot impression, de faire la même chose que de mettre directement des styles en ligne. Sauf que cela n’est pas du tout le cas. Exemple volontairement exagéré : en supposant que votre CSS soit correctement construite, même si vous mettez 10 classes atomiques sur un élément, cela ne pose aucun problème.

p class="mt1 mb1 pl1 automobile aligncenter left w20 etc"

Regardez l’organisation de RÖCSSTI : d’abord on a les styles globaux, ensuite les styles par page, et après la même logique pour les media-queries. L’idée est toujours d’aller du plus général au plus particulier, ce qui permet de bénéficier un maximum de la cascade CSS.

En supposant qu’il faille juste mettre à jour une valeur sur la media-query smartphone, cela se fera aisément via :

@media screen and max-width: 640px {
.etc {
margin-top: 0;
}
}

Et le problème est réglé. Bien sûr, cela suppose que votre CSS soit parfaitement ordrée et structurée, que vos sélecteurs soient parfaitement pondérés. Une évidence bien sûr ! ;)

C’est moche de mettre plusieurs classes sur un élément

Là, j’ai vraiment envie de dire : et alors ? Cela dérange qui ? Et la définition de la beauté c’est quoi ? Il faudra des arguments un peu plus costauds que ça, car il est tout à fait possible d’avoir plusieurs classes sur le même élément, et cela ne dérange personne.

Cas extrême : même si vous aviez 50 classes attachées à un élément, personne n’en aura rien à cirer (JavaScript ou n’importe quel langage peut quand même manipuler l’élément). Alors effectivement, 50 classes peuvent être compliquées pour celui qui maintient (là on parlerait plus d’arguments de maintenabilité, autant penser en classes uniques et via une approche par modules), mais en soi, l’argument de mocheté est ridicule.

C’est pas sémantique

Si je reprends le propos du point précédent, avec 50 classes, cela ne vous dispensera pas pour autant d’en attacher une 51e qui servira à la sémantique.

J’ajouterai bien que le concept de classe sémantique (à l’exception des microdatas ou de RDFa bien sûr) comme beaucoup de gens le conçoivent (à la main) est un poil subjectif. Une bonne fois pour toutes : la sémantique est bien plus dans les balises employées que dans les classes.

Il y a des classes dont je ne me servirai jamais

Personnellement, sur ma base RÖCSSTI, oui, il peut m’arriver de ne pas utiliser certaines de mes classes. Néanmoins, la perte est proprement minuscule sur une CSS gzippée. Et il y a un système fantastique : les commentaires. Pour cacher ce qui n’est pas utilisé, ce qui disparaitra à la minification.

Au pire, si cela vous dérange, utilisez un pré-processeur et transformez les classes utilitaires en placeholders que vous emploierez avec des extend, ainsi, vous serez sûr de ne pas avoir une classe inutilisée.

L’autre avantage d’avoir ces classes à disposition est tout simplement… de savoir qu’elles sont là. C’est tout simplement pratique de ne pas avoir à tout réinventer lorsque je dois reprendre et mettre à jour.

Conclusion

Comme je l’ai déjà expliqué, les classes atomiques sont un outil. Ni révolutionnairement parfait, ni mauvais. Je ne dis pas que c’est adapté à tout, mais il serait dommage de se priver de ses avantages. Cela n’interdit pas la sémantique, et ce ne sont pas des styles en ligne. Comme toujours, cela dépend du cerveau qui va les utiliser à bon escient. Ou pas.

J’ai comparé plusieurs de mes sites avec CSS Stats, les chiffres sont éloquents entre les derniers sites où je les ai pas mal utilisées comme BrieF’R Formations et d’autres sites plus « anciens » où je ne les utilisais pas : le nombre de sélecteurs, de règles, leur ré-utilisabilité, cela saute aux yeux.

Le second billet va arriver d’ici peu… le voici : les classes atomiques en CSS, les avantages.

Permalien :

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1600


Aucun commentaire pour le moment.

Ajouter un commentaire









L'option « Se souvenir de mes informations » utilise un cookie, elle ne sera pas effective si vous les avez désactivés.

Les balises HTML ne seront pas interprétées, il est donc inutile d'en mettre. Par contre, les sauts de lignes de votre commentaire seront pris en compte, ne mettez donc pas de <br />, le site s'en chargera. Bien sûr, un commentaire vide ne sera pas ajouté !

L'auteur (autrement dit moi) n'est pas responsable des éventuelles fautes d'orthographe dans les commentaires.
Tout propos raciste et/ou insultant sera supprimé sans préavis. Les commentaires hors de propos destinés à faire de la pub pour des sites seront également supprimés sans ménagement.

Je vous prie de me pardonner, j'ai énormément de mal à lire le "langage" SMS, il n'est donc pas du tout interdit de s'abstenir de l'utiliser. Qui plus est, vous avez sûrement un clavier digne de ce nom et pas celui d'un téléphone portable. Ne vous gênez pas pour utiliser l'option "Prévisualiser" si vous voulez vous relire avant de poster, je vous en remercie d'avance !

Cet article a été écrit par Nicolas Hoffmann.

Ce site est la propriété de Nicolas Hoffmann.
Tous droits réservés, les textes du blog sont publiés sous licence CC BY-NC-SA.