CSS atomiques, CSS modules, CSS de demain ?

raphael 
<div class="clearfix red left Fz0-large">

ça picote ou pas ?

Dans notre métier, il est constamment nécessaire de se remettre en question. CSS n’échappe pas à la règle et je l’ai remarqué en publiant notre Convention de bonnes pratiques CSS sur Alsacréations.
Les commentaires n’ont pas été tendres sur certaines parties des slides, et il est normal de se poser des questions.

Aujourd’hui (enfin ça fait bien 3-4 ans déjà), on entend de plus en plus parler de notions de « CSS atomiques », voire de « modules CSS », qui vont parfois opérer un virage à 180 degrés (transform: rotate(0.5turn);) par rapport à ce que nous considérons comme étant des bonnes pratiques.

J’ai encore un avis partagé sur le sujet, globalement je suis convaincu que dans certains cas, de temps à autre, pouvoir bénéficier de certaines classes « utilitaires » réutilisables et simples à comprendre et transmettre est un réel avantage… mais aller plus loin ? Systématiquement ?

En attendant de me forger un avis, voici ma liste de lecture à venir sur ce thème délicat :

9 réflexions au sujet de « CSS atomiques, CSS modules, CSS de demain ? »

  1. En fait on s’en fout de comment sont écrits le styles. Les CSS sont interprétées par les navigateurs, lues par des développeurs. Les deux doivent pouvoir faire leur job, c’est tout ce qui compte au final.

    Chaque méthode a ses avantages et inconvénients (et on peut faire bien ou de la merde avec chacune d’entre elles) et sont là pour répondre à un besoin, des problèmes particuliers.

    Comprendre les avantages et les inconvénients de chaque technique permet de faire un choix éclairé.
    Ce sont l’ organisation, la documentation, les conventions définies dans une équipe qui feront un code maintenable, efficace, conforme aux objectifs que l’on s’est fixé.

    Mon avis sur les différentes méthodes :

    Avec acss, tu peux décider de ne plus écrire de CSS et seulement d’éditer du HTML. Idéal pour les perfs, la mise en place rapide, le partage entre projets.
    Des désavantages ? c’est moche, il faut certainement s’y habituer et il faut « apprendre » la syntaxe, beaucoup de classes

    Atomic comme tachyons ou autres : même idée, implémentée différemment. Tu prends ce dont tu as besoin, le but étant de réduire au minimum les styles.
    Moins de CSS, plus de classes

    BEM, SUIT : minimiser les effets de la cascade, les conflits de spécificités avec une approche par composants, quelques classes utilitaires, une structure de fichiers assez stricte (à la ITCSS).
    Les classes sont un peut chargées (noms longs) mais explicites. Les classes utilitaires se rapprochent de atomic et permettent de prototyper rapidement puis de passer à la syntaxe quand trop de classes utilitaires. (faut être inspiré pour le nommage)

    Classes + cascade (je sais pas trop comment l’appeler, un peu l’idée de SMACSS pour ce que j’ai pu voir)
    Équilibre CSS / HTML, possibles problèmes de cascade / spécificité / poids à surveiller.

    Minimum de CSS, comme (mal) présenté dans l’article de ALA, on s’appuie au max sur la structure HTML, roles, attributs ARIA, l’essentiel est dans les styles.
    Ça peut facilement partir en sucette à tous les niveaux. Demande des connaissances fines en CSS et HTML (l’exemple ARIA est faux par exemple dans l’article ALA !!)
    Est-ce qu’il est impossible de faire du code maintenable… probablement pas (dépend de la taille du projet à mon avis)

    CSS modules, c’est adapté aux SPA ou des approches par composants, le but étant d’éviter le « global scope » de CSS. On gère tout ce qui concerne le composant dans son propre fichier, l’accent est mis sur la maintenabilité.
    layout, responsive…

    Rien n’empêche d’utiliser tachyons, puis passer à du BEM ou autre convention avec SASS avec les « placeholder selectors » ou utiliser des classes atomiques avec les CSS modules…

    Il n’y a pas un camp à choisir… des choix éclairés à faire et contrôler que le résultat final est conforme aux objectifs qu’on s’est fixés.

  2. Je pense surtout que le « one size fits all » est impossible, et que ça reste la typologie du projet + le niveau de compétences des équipes qui bosseront dessus qui drive le choix de methode.

    De L’ACSS est particulièrement adapté au webapp gerée par composants, encore plus lorsqu’un language côté serveur les génèrent. Par contre pour du single page ou un « pauv' » jeu concours, aucun intérêt.

  3. Je pense qu’il n’y a pas de solution unique. L’idée c’est de comprendre les outils qui sont à notre disposition et de les utiliser à bon escient; de prendre des décisions sans apriori.

    Comme la suggérer Raphael dans un commentaire sur alsacreations, ce qui devrait décider des méthodes á adopter c’est l’environnement technologique, la compétence des intervenants, les moyens en personnel, le cahier des charges, etc.

    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 con, je pense que ça frôlerait les 99.99% (sémantique ou atomique selon l’humeur du moment).

    Comme on dit aux US: « Whatever floats your boat… »

  4. Des choses vont changer, ça c’est sûr. Typiquement, l’approche OOCSS va être toujours valable, mais son premier principe (séparer le design d’un module/élément de son positionnement) va être appliqué différemment : typiquement, les joyeusetés comme Grid Layout vont permettre de sculpter de manière globale nos éléments « standalone » (j’en discutais hier soir à Sud Web).

    Peut-être dans certains cas, l’approche atomique pourra être remplacée par un grid « global », peut-être pas dans d’autres. J’avoue que même si je n’ai pas encore eu l’occasion de m’en servir sérieusement, ça promet des choses intéressantes. Et ce qu’on a appris nous servira quand même, mais autrement.

    Par contre oui, pour ceux qui ne l’ont pas encore fait, il va sérieusement falloir faire le deuil d’un graal de la méthode qui marche partout dans tous les cas et qui lave plus blanc (et qui fait revenir l’être aimé dans le scope global). En même temps, à chercher des chimères, on se prend des cornes de licornes dans le fondement…

  8. J’ai déjà la migraine, les bonnes pratiques changent tous les 2 mois, impossible de maintenir une stack technique :/

  9. Bonjour,

    je viens vous alerter … attention ! Pas une seule fois, dans l’article ou les commentaires, je ne vois le mot « plaisir ». Pourtant, ça peut aussi légitimer certains choix, après tout.

    Et pour répondre à la question :

    <

    div class= »clearfix red left Fz0-large »>
    ça picote ou pas ?

    Sans jeter à la pierre à ceux qui aiment, à mes yeux, ça ne picote pas, ça brûle: ça m’éloigne du plaisir de coder, ça m’éloigne des préoccupations singulières de mon client, ça m’éloigne du côté artisanal de mon activité, j’aime pô. Je reconnais toutefois que je travaille uniquement sur de petits projets, sans prétention, avec une proximité directe avec mes clients.

    Des fois, je me dis aussi que ça dépend peut-être de la propension qu’on a au départ, de préférer parler aux machines ou aux gens.

Les commentaires sont fermés.