Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Bonnes pratiques en CSS : BEM et OOCSS
Par Tarh_

Le , par Paleo

7PARTAGES

6  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 01/09/2014 à 18:39
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
<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
2  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 12/09/2014 à 9:33
Bonjour et merci pour le partage de votre technique. Un peu hors sujet mais tout à fait intéressante.

Citation Envoyé par SylvainPV Voir le message
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.
2  0 
Avatar de Muchos
Membre expert https://www.developpez.com
Le 18/08/2014 à 1:20
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 «&#8239;les noms de classes transmettent peu ou pas d’information sémantique utile aux machines&#8239;».

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.)
1  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 13/09/2014 à 18:44
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.
1  0 
Avatar de Muchos
Membre expert https://www.developpez.com
Le 17/08/2014 à 15:37
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.
0  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 17/08/2014 à 17:06
Bonjour,

Citation Envoyé par Muchos Voir le message
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.

Citation Envoyé par Muchos Voir le message
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.
0  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 18/08/2014 à 10:15
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.
0  0 
Avatar de black-hawk-down
Membre habitué https://www.developpez.com
Le 18/08/2014 à 13:51
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
0  0 
Avatar de Bisûnûrs
Modérateur https://www.developpez.com
Le 19/08/2014 à 7:59
Citation Envoyé par Tarh_ Voir le message
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.
0  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 13/09/2014 à 21:05
Citation Envoyé par SylvainPV Voir le message
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.

Citation Envoyé par SylvainPV Voir le message
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.
0  0