Discussion :

[Paleo]

Des années durant, j'ai intégré des sites Web et développé des applications JavaScript sans ressentir le besoin d'une méthodologie pour nommer les classes CSS. Puis, les projets grossissant, le code CSS est devenu douloureux…

L'épineux sujet du nommage en CSS est loin d'être fermé. Depuis le début de la décennie, plusieurs auteurs majeurs ont partagé leurs recherches. Ils ont apporté un regard nouveau et sont allés à contrecourant, en rupture avec ce qui faisait jusqu'alors consensus. Je raconte dans cet article mon propre cheminement dans leurs travaux en espérant qu'il sera utile à l'intégrateur Web autant qu'au développeur JavaScript. J'ai cherché en effet une approche adaptée à la fois aux pages et aux applications Web.

Tiré des cours et tutoriels CSS : http://css.developpez.com/cours/ , lire l'article complet : Bonnes pratiques en CSS : BEM et OOCSS

Table des matières :

Introduction
I. OOCSS
II. BEM
III. Pertinence de BEM
III.a. La propreté
III.b. La performance
III.c. La scalability et une architecture par composants
IV. Une syntaxe BEM… jolie !
V. Ingérences transversales et… OOCSS
V.a. À propos d'objets CSS
VI. Cas d'utilisation, partie 1 : HTML
VI.a. Discussion HTML
VII. Cas d'utilisation, partie 2 : CSS avec SASS
VII.a. Discussion CSS
Conclusion

[Muchos]

Merci pour cet article !

Je trouve la méthode BEM très intéressante.

La méthode OOCSS me semble aberrante :

la seule sémantique est obsolète dans la mesure où il nous fait produire du code CSS non-réutilisable.

Selon moi, c'est le contraire ! J'utilise .main-content-title plutôt que .big-blue-title, car mon titre peut changer d'apparence selon la charte, mais sera toujours un titre! En outre, les classes sont aujourd'hui lues par les moteurs de recherche. Leur valeur est donc importante.

[Paleo]

Bonjour,

Selon moi, c'est le contraire ! J'utilise .main-content-title plutôt que .big-blue-title, car mon titre peut changer d'apparence selon la charte, mais sera toujours un titre!

Votre réaction me fait penser que j'ai exagéré pour rien en prenant le gros titre. Je remplace par ".comment-title" vs ".tiny-blue-title" : même argument, moins choquant.

Notez bien que "big(ou tiny)-blue-title" se justifie selon OOCSS à condition qu'il désigne un pattern visuel réutilisable. La FAQ du framework OOCSS explique que la voie sémantique et la voie non-sémantique sont toutes deux valides à condition de rester générique.

Cela dit, votre argumentation est celle des bonnes pratiques des années 2000. Elle est fausse en tout cas dans mon expérience : à chaque fois qu'un client demande une refonte du design, je dois de toute manière refaire aussi le code PHP et le HTML en plus du CSS. Avec une approche (en partie) visuelle les modifications demandées par le client demandent finalement moins de travail.

En outre, les classes sont aujourd'hui lues par les moteurs de recherche. Leur valeur est donc importante.

Auriez-vous une source pour cette info ? C'est la première fois que je lis cela. Il me semble que c'est RDFa la bonne technologie pour préciser plus de sémantique.

[Muchos]

Merci pour votre réponse

Auriez-vous une source pour cette info ?

Et bien non! L'info est répétée sur de nombreux sites spécialisés sans être sourcée

Pour remarque: la dernière spécification HTML du W3C et du WHATWG conseille d'utiliser la valeur des CLASS pour décrire la nature de l'élément plutôt que son apparence.
Néanmoins, unarticle de Nicolas Gallagher (voir 2e paragraphe) estime que cette "bonne pratique" est contre-productive, et ajoute que « les noms de classes transmettent peu ou pas d’information sémantique utile aux machines ».

Peut-être les standards et moi-même sommes vieux jeu Le conseil d'OOCSS sur la dimension claire, générique et sémantique des classes est finalement salutaire; et je me souviens que j'utilise moi-même ponctuellement des classes de ce genre (.floatl, .serif, etc.)

[Paleo]

Merci pour la réponse documentée, la petite phrase du W3C m'avait échappé. Effectivement, on va dire qu'ils sont vieux jeu.

La nuit porte conseil et j'ai retiré le "blue" de "tiny-blue-title" puisque le but n'est vraiment pas de choquer. En fait avec OOCSS on repère des répétitions visuelles puis on leur trouve un nom. Et parfois le pattern s'applique a tellement de cas qu'il est bien difficile de le rattacher à un nommage sémantique, alors on se rabat sur ce qu'on voit : un petit titre bleu.

[black-hawk-down]

Merci beaucoup pour cet article. Il tombe à point nommé, je comptais justement faire du refactoring sur mon CSS afin de tout bien identifier clairement et cherchais une méthode simple à mettre en place. Bah c'est fait, merci

[Bisûnûrs]

La nuit porte conseil et j'ai retiré le "blue" de "tiny-blue-title" puisque le but n'est vraiment pas de choquer. En fait avec OOCSS on repère des répétitions visuelles puis on leur trouve un nom. Et parfois le pattern s'applique a tellement de cas qu'il est bien difficile de le rattacher à un nommage sémantique, alors on se rabat sur ce qu'on voit : un petit titre bleu.

Et tout dépend du besoin. Chaque cas d'utilisation doit être réfléchit dans le contexte du développement du site.

[SylvainPV]

Content de voir que je ne suis pas le seul à trouver la syntaxe BEM affreuse

On a essayé de me mettre à ce BEM sur un projet et rien à faire, j'ai détesté. Je n'ai jamais raisonné avec cette séparation élément / modifieur : pour moi tout est propriété et se place au même niveau. Typiquement, le designer me fournit une charte graphique avec d'une part les couleurs, d'autre part les styles (bordure, ombres, texte etc..) et enfin les mockups. Je reprends ça très simplement en écrivant des classes réparties dans 3 fichiers colors.css, styles.css et layout.css. Puis j'ai juste à assembler les classes ensemble:

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

<a class="red-bg button-big centered">

Combiner les classes n'augmente pas la spécificité, c'est le développeur qui l'augmente en écrivant des sélecteurs inutilement complexes. Si l'on est ordonné et que l'on prend le temps de bien catégoriser les éléments pour leur faire correspondre les bonnes propriétés de base, la surcharge spécifique est plutôt rare. On peut aussi demander au designer de caractériser ses éléments avec ce vocabulaire et l'intégrer à la charte graphique, ça peut beaucoup aider si les deux parties suivent la même démarche.

Et puis, pourquoi faudrait-il s'interdire d'utiliser les noms de tags ? C'est un élément sémantique essentiel, bien plus que ne l'est un nom de classe. On en vient à réinventer la roue avec des .ordered-list > .list-item au lieu de ol > li

[Paleo]

Bonjour et merci pour le partage de votre technique. Un peu hors sujet mais tout à fait intéressante.

Et puis, pourquoi faudrait-il s'interdire d'utiliser les noms de tags ? C'est un élément sémantique essentiel, bien plus que ne l'est un nom de classe. On en vient à réinventer la roue avec des .ordered-list > .list-item au lieu de ol > li

À mon sens il n'est effectivement pas utile de réinventer la roue et on peut souvent réutiliser le nom de l'élément comme nom de classe. Par exemple .Slider-li utilise -li dans le sens de "list item", c'est court et connu de tout le monde.

Ensuite, pourquoi pas sélectionner sur les noms de tags eux-même ? Il y a plusieurs raisons mais la plus importante est la séparation des contextes qui permet la scalability. Le cas de la sélection d'un enfant avec ">" ne pose pas de problème de séparation de contexte, il me semble donc que c'est une option utilisable. Il reste toutefois les raisons avancées par OOCSS : le principe de séparation entre la structure HTML et l'apparence en CSS. On peut par exemple utiliser un .Slider-h1 pour désigner le premier titre du slider, mais implémenter en HTML avec un <h3> pour des raisons d'accessibilité et/ou de cohérence avec le reste du document.

[SylvainPV]

Le sélecteur enfant est nécessaire seulement lorsque l'on travaille avec des éléments au contenu HTML variable ou pouvant évoluer au cours du projet ; les règles de mise en page par exemple. Si on utilise la classe slider pour désigner un carousel d'images, on sait à l'avance qu'une image ne contiendra pas de listes auquel cas .slider li me paraît être un sélecteur tout à fait convenable.

L'exemple du .Slider-h1 est intéressant, mais il s'agit selon moi d'un cas exceptionnel: les balises h1 à h6 présentent un caractère sémantique commun, celui de heading, et le niveau aurait pu être deviné par l'arborescence ; ces balises sont donc mal pensées, c'est un défaut de la norme HTML4 qui a été critiqué plus d'une fois ; mais avec HTML5, on peut le corriger par l'utilisation de <section> qui réinitialise les niveaux de heading. Le premier header du slider peut donc être un <h1> peu importe où on le place dans le document, sans nuire à l'accessibilité. Une autre option est d'écrire 6 fois le sélecteur avec chaque niveau de heading (ce qui met en évidence le défaut de la spec).

Je ne vois pas de raison de systématiquement séparer structure et apparence. Lorsque l'on décrit un style, certaines propriétés dans la formulation sont uniques et indépendantes (le bouton d'action principal est rouge) tandis que d'autres sont directement liées à la structure (les boutons de ce formulaire sont alignés à droite). S'il fallait séparer totalement structure et apparence, cela signifierait ne plus utiliser d'espaces dans les sélecteurs CSS, ce qui appauvrirait énormément le langage.

[Paleo]

Le sélecteur enfant est nécessaire seulement lorsque l'on travaille avec des éléments au contenu HTML variable ou pouvant évoluer au cours du projet ; les règles de mise en page par exemple. Si on utilise la classe slider pour désigner un carousel d'images, on sait à l'avance qu'une image ne contiendra pas de listes auquel cas .slider li me paraît être un sélecteur tout à fait convenable.

C'est justement ça le truc : même si on crée un diaporama pour afficher des images, pourquoi ne serait-il pas réutilisable pour afficher autre chose que des images ? C'est toute l'idée de la scalability : rendre générique, pour faire du grand en multipliant le petit.

En outre .slider li est moins performant que .Slider-li. Sur une page Web ça ne joue peut-être pas mais dans une application Web si.

L'exemple du .Slider-h1 est intéressant, mais il s'agit selon moi d'un cas exceptionnel: les balises h1 à h6 présentent un caractère sémantique commun, celui de heading, et le niveau aurait pu être deviné par l'arborescence ; ces balises sont donc mal pensées, c'est un défaut de la norme HTML4 qui a été critiqué plus d'une fois ; mais avec HTML5, on peut le corriger par l'utilisation de <section> qui réinitialise les niveaux de heading. Le premier header du slider peut donc être un <h1> peu importe où on le place dans le document, sans nuire à l'accessibilité.

Concernant l'accessibilité des titres HTML 5, voici une ressource qui incite à s'en tenir aux anciennes pratiques : http://accessiblehtmlheadings.com/ . J'ignore si elle fait consensus, je n'ai pas d'idée arrêtée sur le sujet. Le nommage par des classes permettra de changer d'avis sans effet de bord, selon les bonnes pratiques qui finiront bien par se dégager. On peut se rappeler de la balise <hgroup> standardisée puis devenue obsolète : une classe .hgroup aurait évité de devoir retoucher aux fichiers CSS.

Il y a d'autres cas : une classe .img est utilisable sur les balises <svg> par exemple. Et j'ai eu plus d'une fois le cas d'une classe .li appliquée sur des <div> pour des raisons pratiques de génération du PHP, à cause d'une API qui rend les classes configurables mais pas les balises.

Autre exemple. Reprenons notre diaporama prévu pour agrémenter une page Web, sa place sémantique est dans une <section>. Admettons maintenant qu'on veuille le réutiliser mais cette fois-ci comme artifice visuel pour afficher le contenu-même de l'article, disons, une sous-partie de l'article en mode mobile seulement. Alors une balise <div> pour le conteneur sera plus adaptée, ainsi que le respect des niveaux de titre.

[SylvainPV]

C'est bien beau de penser à la scalabilité, mais il y a une limite à tout: un diaporama de listes, je n'ai aucune idée de ce à quoi ça ressemble. Et si on me demandait d'en faire un, je doute qu'il ressemble suffisamment à mon diaporama d'images pour que je puisse réutiliser la classe slider-li. Quant à la différence de performance, elle est infime et contre-balancée par le code supplémentaire à charger dans le HTML: "class='slider-li'" * nbItems.

Utiliser des noms de tags comme classes est très confusant si le tag en question n'est pas le même: par exemple avec un div.li, il ne faut pas oublier de déclarer display:list-item sinon certaines propriétés propres aux listes ne s'appliqueront pas ; de la même façon, on n'applique pas le même CSS à une balise <svg> qu'à une balise <img>. Je trouve que ça embrouille plus que ça n'aide.

En parlant de cette API PHP qui crache des <div>, je crois que tu as mis le doigt sur le problème. C'est sans doute ça que je crains le plus avec le fait de ne plus tenir compte du type d'éléments employés mais seulement de leurs classes: se retrouver avec une soupe de <div>. C'est le nouveau fléau du CSS après la mise en page par tableaux: on utilise systématiquement des éléments neutres, div et span, pour être sûr de contrôler entièrement leur style ; et tant pis si l'on réduit à néant la sémantique du document et les variations (utiles !) des propriétés de base de chaque élément selon les user agent stylesheets.

[Paleo]

C'est bien beau de penser à la scalabilité, mais il y a une limite à tout: un diaporama de listes, je n'ai aucune idée de ce à quoi ça ressemble

Dans l'immédiat je n'en retrouve pas mais j'ai déjà vu du texte formaté dans des diaporamas extra-larges sur des sites Bootstrap.

Dans le carrousel de Gandi il y a du texte : https://www.gandi.net/ . Les <li> sont stylés sur le nom de l'élément, donc il n'est pas possible de mettre des listes à puces dans les textes, c'est une limitation.

Quant à la différence de performance, elle est infime et contre-balancée par le code supplémentaire à charger dans le HTML: "class='slider-li'" * nbItems.

Le temps de chargement et celui de l'exécution sont deux choses différentes. D'un côté la latence lorsqu'on navigue, de l'autre la fluidité à l'intérieur de la page ou de l'application Web.

L'argument de la prise de poids du code HTML d'une page Web est pertinent. Mais les répétitions dans le HTML se compressent bien, Nicolas Gallagher rappelle qu'il faut comparer les versions gzippées. À savoir aussi : Nicole Sullivan affirme avoir réduit significativement la taille des codes HTML et CSS de ses clients (ici, dans les dernières diapo) … cela dit, c'était peut-être l'effet refonte/factorisation, et puis il s'agissait de OOCSS et non pas de BEM, BEM ne peut réduire que le code CSS.

Dans le cas d'une application JavaScript, l'argument ne joue plus du tout. Une appli JS charge séparément les templates et les données JSON, puis crée dynamiquement les éléments dans le DOM.