BEM, est-ce un bon choix ?

Bonjour,
Je me questionne sur les pratiques d'écriture de feuilles de style et j'aimerais adopter une convention que je ne serais pas seul à utiliser et connaître.

J'ai donc clairement identifié les grands noms; SMACSS, OCSS et BEM. Le dernier me paraît plutôt pertinent (mais pas totalement sinon je ne posterais pas...) donc c'est plutôt celui là qui m'intéresse. J'ai donc essayé de me projeter et d'imaginer mentalement des cas particuliers de son usage.
Personnellement j'organise mes feuilles de style avec sass sous cette forme:
J'ai quatre répertoires variables, utils, components, et partials. C'est inutile de vous détailler entièrement la hiérarchie et les interactions de mes fichiers, mais sachez que components contient différents fichiers dont chacun correspond à une "unité d'interface", j'ai vite vu que cela correspondait aux éléments en BEM.

Maintenant je vous présente un exemple: imaginez que mon interface utilise des boutons (c'est fréquent admettez-le). J'ai donc un élément de classe button avec éventuellement des sous éléments button__icon et des états button--cancel, button--confirm, etc... Tout ça je le met dans mon fichier _button.sass du répertoire components. Mais, mon bouton va nécessairement se retrouver dans d'autres éléments indépendants (form, au hasard).
Donc déjà je trouve que c'est un peu une entrave à la logique de cette convention dans le sens où des éléments présumés atomiques s'imbriquent (oui on ne parle pas de combinaison mais bien d'imbrication puisque d'un point de vue logique comme sémantique, le bouton se retrouve dans le form).
Donc si je suivait BEM à la lettre, je devrais plutôt créer un sous élément form__button, et faire ainsi pour tous les éléments qui utilisent un bouton, et ainsi dupliquer comme jamais.

Ou sinon, je m'en fiche, j'imbrique mes atomes (cette phrase n'a pas de sens ça m'irrite), et pour gérer les éventuelles variations de mon bouton selon l'élément dans lequel il se trouve, je lui crée des états button--form, etc...
Mais c'est là que ça me pose un problème quant à la structure sass que je vous ai décrite: mes différents états je vais les définir dans le fichier _button.sass (ça semble évident); alors des styles qui sont liés au bouton mais inhérent à son parent, vont être définis dans le fichier du bouton. Moi j'aimerais le mettre dans le fichier du form mais c'est le bordel alors.

Bon vous devez voir quel est mon problème maintenant (j'espère). Mais ce serait délirant que personne ne ce soit posé la question avant moi donc je suis sûr qu'il y a une explication.

Par ailleurs, le point fort de BEM est de régler les problèmes d'héritages de CSS et d'ameliorer la lisibilité du code (je ne suis pas du tout d'accord avec ce second point soit dit en passant).
Mais quant au premier point je ne comprend pas pourquoi c'est un problème, CSS met en avant cette caractéristique (c'est meme dans son nom), et c'est très utile pour factoriser son code d'une façon qui me paraît plus lisible et élégante que BEM.
Moi j'aurais envie (et c'est plutôt ce que je fait actuellement) d'user de l'héritage pour créer mon élément button, qu'il puisse avoir un état warning avec un background orange, mais que mon élément message (par exemple) puisse lui aussi avoir un état warning qui hérite des mêmes propriétés. Et si chacun d'entre eux se comporte différemment sur certaines propriétés de cet état, j'ai juste à imbriquer mes selecteurs pour leur donner à chacun leur propriétés particulières en plus du background orange.

Bon voilà c'est le monologue que je me suis fait en me documentant sur le sujet; mais vous qu'en pensez-vous ? Vous utilisez quoi ? Pourquoi ?

Bonjour Julien,

Je suis également en réflexion concernant la méthodologie CSS et j'envisage la création d'un framework. En effet, les solutions très en vogue depuis quelques années s'avèrent très limitée au regard du mon contexte professionnel (de lourds projets chez l'annonceur et non en agence).
J'ai d'ailleurs également ouvert un sujet ressemblant davantage à un monologue il y a deux jours (ça peut t’intéresser) en raison de mes réflexions sur ce projet.
En tous cas, il m’intéresserait de suivre tes avancées. On peut prendre contact en privé si tu veux.

Concernant tes interrogations :

La notion Block-Element de BEM laisse en effet présager d'un effet patchwork sur l'application avec, pour reprendre ton exemple, des boutons stylisés différemment dans les différents block. BEM est un principe et non une solution. Pour éviter cet effet patchwork, une solution est de passer par un préprocesseur et de créer un mixin 'button'. Ainsi, chaque bouton des blocks auraient le même style. Mais chaque block resterait indépendants (au delà de cette dépendance au mixin).

Pour la solution 'atomique' que tu proposes, c'est un non-sens. Pour chaque élément tu serais obligé de créer un modifieur pour chaque type de block de l'application. Tu exploserais la poids de ta CSS avec un tas de classes inutilisées ; tu devrais créer un tas de modifieurs pour chaque éléments à chaque ajout d'un nouveau block ; tu te retrouverais avec une CSS impossible à maintenir.

Sur l'héritage ça serait intéressant... si l'héritage pouvait être transmis par un élément sans être y être appliqué. L'attribut héritable serait alors une information transparente circulant d'une élément à l'autre. Ce n'est pas le cas donc pas vraiment exploitable de manière fiable et généralisé.

Si les éléments sont trop imbriqués c'est peut-être qu'ils ne sont pas assez "atomisés" au départ. Il faut peut-être prévoir des éléments plus succincts.

Merci de vos réactions,
Erwan j'ai consulté ton topic qui est très intéressant puisqu'il ajoute à mon questionnement la problématique de la performance, ça me donne envie comme tu l'as fait de mettre en œuvre des protocoles expérimentaux pour voir comment l'efficacité d'interprétation des CSS varie selon leur structure. Néanmoins d'une part, la méthode rigoureuse consisterait plutôt à se documenter sur le processus précis de lecture des CSS par les différents moteurs et de déterminer ainsi par le calcul quelles structures sont les plus efficaces (ce serait de la lourde algorithmique théorique...); et d'autre part je suis un peu sceptique quant à la pertinence de cette problématique, selon moi, l'enjeu aujourd'hui demeure plutôt dans les performances de chargement des fichiers. Je vais regarder ça de plus près pour me faire une idée mais en l'état c'est mon hypothèse.

Donc moi la question que je me posais, indépendamment des performances, c'est quelles structure CSS sont les plus adaptées pour nous, mammifères. Plus j'y réfléchi et plus je trouve que les promesses de clarté et de modularité de BEM ne sont pas vraiment remplies.
J'aime beaucoup ce concept d'atome (je l'avais découvert d'avantage dans cet article sur le design atomique) qui nous pousse à penser en terme de module; mais j'aime beaucoup aussi l'idée de ce que j'appellerai une modularité inter-modules car (et j'en viens à ton commentaire Olivier), je trouve pertinent de considère un formulaire (qui contient un bouton donc) comme un élément en lui-même, néanmoins lui-même contient des atomes (le bouton, mais d'autres choses encore). Donc ce n'est pas un atome. Le design atomique appelle ça une molécule, mais je ne suis pas encore tout à fait d'accord. L'idée qui me plait c'est celle de l'arborisation; à l'image du DOM (ce que je trouve pertinent pour un langage supposé interagir avec lui). Donc quand je parle de modularité inter-modulaire, le concept est foireux parce qu'il n'emploie pas les bons termes; c'est plutôt une arborescence modulaire en fait.

J'imagine un arbre dont chaque branche correspond à un module, ou un sous-module, etc... Et dont chaque noeud exprime une différenciation du module parent (analogiquement à la représentation arborisée de l'évolution en biologie).

Donc chaque noeud de l'arbre est un module qui descend de son module parent, et je considère les extrémités des branches comme des noeuds, qui ont la capacité de donner deux (ou plus) nouvelles branches quand le projet évolue par exemple.

Chaque noeud (donc chaque module) peut prendre plusieurs états qui sont hérités de ses parents.

Enfin, et j'en viens ai terme modulaire que j'avais apposé à celui d'arborescence; à la manière d'un platane (j'ai peur de m'engouffrer en métaphore), les différentes branches peuvent créer des boucles, et ainsi avoir des noeuds communs. Je m'explique: mon arbre à un noeud bouton et un noeud formulaire; plutôt que de différencier le bouton indépendamment pour le cas où il se trouve dans un formulaire, on crée un noeud commun avec la branche du formulaire. Ce lien doit avoir une direction, c'est essentiel pour définir quel élément va dans l'autre. Cette image permet selon moi de clairement exprimer à la fois une imbrication et une différenciation qui est inhérente à cette imbrication.

Je trouve mon explication beaucoup trip verbeuse et alambiquée donc j'aimerais bien faire un schéma au crayon pour exprimer ça de façon moins décousue. Et ça me permettra peut être aussi de constater des failles dans mon modèle.

En fin de compte (et je m'en rend compte maintenant), j'ai l'impression que je pense de plus en plus en terme de logique relationnelle façon POO (mais en CSS quoi...) de telle façon que mes classes CSS sont au sens objet du terme: des classes. Et que j'essaie de créer des liens relationnels entre elles, je vais réfléchir dans mon schéma à la pertinence de ce modèle et tester des analogies du types one to one uni/bi-directionnel, many to one etc...

Bon bref je me suis pas relu j'espère que c'est pas trop n'importe quoi ce que j'ai ecrit.

Erwan pourquoi pas un framework, j'ai plus en tête un genre de pré-processeur qui orienterait de façon substantielle la manière d'organiser les CSS (un peu comme rails oriente substantiellement la façon d'organiser un projet).
Modifié par juliendargelos (12 Aug 2016 - 15:35)

Le problème sur ces sujets, vient aussi du type de projet sur lequel on bosse, du design du site et de son graphisme. Souvent on travaille sur des projets dans une certaine ligne, avec souvent le/les mêmes designer et graphistes.

Par exemple un site qui a été pensé très modulaire avec beaucoup de travail en amont pour rationaliser les contenus et hiérarchiser l'information sera probablement un bonheur pour l'oocss et deviendra inutilement verbeux pour les CSS atomiques. À l'inverse un site plus «libre» ou les éléments sont peu rationalisé sera un plaisir avec des CSS atomiques et un cauchemard à implémenter l'oocss.
SMACSS est plus une méthode d'organisation qui ressemble pas mal à BEM et se trouve plus «au milieu». Ce sont deux méthodologies qui, je trouve, ne brillent nulle part mais ne pêchent nulle part. Si on veut adopter une méthodologie applicable à tous les projets je partirait plutôt là-dessus.

a écrit :
Maintenant je vous présente un exemple: imaginez que mon interface utilise des boutons (c'est fréquent admettez-le). J'ai donc un élément de classe button avec éventuellement des sous éléments button__icon et des états button--cancel, button--confirm, etc... Tout ça je le met dans mon fichier _button.sass du répertoire components. Mais, mon bouton va nécessairement se retrouver dans d'autres éléments indépendants (form, au hasard).
Donc déjà je trouve que c'est un peu une entrave à la logique de cette convention dans le sens où des éléments présumés atomiques s'imbriquent (oui on ne parle pas de combinaison mais bien d'imbrication puisque d'un point de vue logique comme sémantique, le bouton se retrouve dans le form).
Donc si je suivait BEM à la lettre, je devrais plutôt créer un sous élément form__button, et faire ainsi pour tous les éléments qui utilisent un bouton, et ainsi dupliquer comme jamais.

Cela me semble une mauvaise compréhension de BEM: Le principe est justement d'identifier des éléments qui pourront se trouver dans un formulaire mais tout aussi bien ailleurs. Il y a évidemment des points délicats, mais c'est plutôt des questions de choix que l'on doit faire par rapport à ce que l'on a à intégrer.

juliendargelos a écrit :
Néanmoins d'une part, la méthode rigoureuse consisterait plutôt à se documenter sur le processus précis de lecture des CSS par les différents moteurs et de déterminer ainsi par le calcul quelles structures sont les plus efficaces (ce serait de la lourde algorithmique théorique...);

Les tests que j'effectue n'ont pas pour objectif de m'indiquer une voie mais plutôt de m'en ouvrir. Je ne pense pas que la quête d'une structure meilleure que toutes les autres soient pertinent. D'une part parce que les moteurs de rendu sont pensés pour traiter au mieux les différentes structurations et peuvent évoluer dans le temps. D'autre part parce qu'en fin de course il y a un intégrateur humain évoluant dans un contexte professionnel humain orienté par des contraintes humaines.

juliendargelos a écrit :
je suis un peu sceptique quant à la pertinence de cette problématique, selon moi, l'enjeu aujourd'hui demeure plutôt dans les performances de chargement des fichiers. Je vais regarder ça de plus près pour me faire une idée mais en l'état c'est mon hypothèse

A l'heure de la 4G, le chargement d'un CSS, même très lourd (1Mo), n'est plus vraiment un problème.

juliendargelos a écrit :
Erwan pourquoi pas un framework, j'ai plus en tête un genre de pré-processeur qui orienterait de façon substantielle la manière d'organiser les CSS (un peu comme rails oriente substantiellement la façon d'organiser un projet).

Le choix du framework est par défaut de ma part. Je n'ai pas les compétences techniques pour réaliser un pré-processeur.
Mais si tu te lance dans un tel projet, fait moi plaisir en permettant de joindre CSS et JS. Des modules complets, styles et interactions, serait alors définit dans un fichier unique (puis compilé en fichiers CSS et JS). La modularité serait alors maximum .