@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. ]]> text/html https://www.nicolas-hoffmann.net/source/1601-Les-classes-atomiques-en-CSS-les-avantages.html#comment158472 Kaelig Mon, 16 Dec 2013 10:18:41 +0100

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 !! ]]> text/html https://www.nicolas-hoffmann.net/source/1601-Les-classes-atomiques-en-CSS-les-avantages.html#comment158471 Gaël Mon, 09 Dec 2013 12:29:53 +0100

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. ]]> text/html https://www.nicolas-hoffmann.net/source/1601-Les-classes-atomiques-en-CSS-les-avantages.html#comment158470 Nico Sun, 08 Dec 2013 00:09:24 +0100 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 ]]> text/html https://www.nicolas-hoffmann.net/source/1601-Les-classes-atomiques-en-CSS-les-avantages.html#comment158469 nicod_ Sat, 07 Dec 2013 19:54:36 +0100

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, `

— 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 ! ]]> text/html https://www.nicolas-hoffmann.net/source/1601-Les-classes-atomiques-en-CSS-les-avantages.html#comment158468 Vincent Sat, 07 Dec 2013 18:01:43 +0100

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 ]]> text/html https://www.nicolas-hoffmann.net/source/1601-Les-classes-atomiques-en-CSS-les-avantages.html#comment158467 Pascal Sat, 07 Dec 2013 01:52:11 +0100