Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 216
    Points : 594
    Points
    594

    Par défaut Bonnes pratiques en CSS : BEM et OOCSS

    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

  2. #2
    Membre expert
    Avatar de Muchos
    Homme Profil pro
    Sans emploi
    Inscrit en
    décembre 2011
    Messages
    1 700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Ardennes (Champagne Ardenne)

    Informations professionnelles :
    Activité : Sans emploi
    Secteur : Arts - Culture

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 700
    Points : 3 842
    Points
    3 842
    Billets dans le blog
    6

    Par défaut

    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.

    ---
    Debug the Web together!

  3. #3
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 216
    Points : 594
    Points
    594

    Par défaut

    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.

  4. #4
    Membre expert
    Avatar de Muchos
    Homme Profil pro
    Sans emploi
    Inscrit en
    décembre 2011
    Messages
    1 700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Ardennes (Champagne Ardenne)

    Informations professionnelles :
    Activité : Sans emploi
    Secteur : Arts - Culture

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 700
    Points : 3 842
    Points
    3 842
    Billets dans le blog
    6

    Par défaut

    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.)

    ---
    Debug the Web together!

  5. #5
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 216
    Points : 594
    Points
    594

    Par défaut

    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.

  6. #6
    Membre habitué
    Homme Profil pro
    Intégrateur Web
    Inscrit en
    juillet 2014
    Messages
    92
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Intégrateur Web
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : juillet 2014
    Messages : 92
    Points : 152
    Points
    152

    Par défaut

    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

  7. #7
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    janvier 2004
    Messages
    9 860
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : janvier 2004
    Messages : 9 860
    Points : 16 239
    Points
    16 239

    Par défaut

    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.

  8. #8
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 238
    Points : 9 474
    Points
    9 474

    Par défaut

    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
    One Web to rule them all

  9. #9
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 216
    Points : 594
    Points
    594

    Par défaut

    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.

  10. #10
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 238
    Points : 9 474
    Points
    9 474

    Par défaut

    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.
    One Web to rule them all

  11. #11
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 216
    Points : 594
    Points
    594

    Par défaut

    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.

  12. #12
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 238
    Points : 9 474
    Points
    9 474

    Par défaut

    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.
    One Web to rule them all

  13. #13
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 216
    Points : 594
    Points
    594

    Par défaut

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

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

Discussions similaires

  1. Bonnes pratiques de protections individuelles
    Par Community Management dans le forum Sécurité
    Réponses: 22
    Dernier message: 05/04/2013, 12h47
  2. Bonnes pratiques de design : dans le code Java ou dans le CSS?
    Par Florent23 dans le forum GWT et Vaadin
    Réponses: 6
    Dernier message: 31/12/2010, 14h02

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo