CSS, l’âge de raison

Openweb.eu.org > Articles  > CSS, l’âge de raison

Abstract

Dans la suite directe de « De l’intégrateur au développeur Front-end… », Nicolas Hoffmann vous propose une réflexion sur les dogmes de CSS et pourquoi la pratique invite à les remettre légèrement en question.

Article

Après de nombreuses années à apprendre à maîtriser la syntaxe et le pouvoir de CSS, le temps est maintenant venu pour le développeur front-end de faire évoluer sa manière d’écrire des feuilles de style et de remettre en cause certaines habitudes un peu trop bien ancrées.

Voici quelques pratiques établies qu’il va falloir reconsidérer :

  • le recours systématique à des identifiants pour les éléments uniques dans la page comme une barre de contenus par exemple (#sidebar) ;
  • ne pas nommer ses classes CSS en fonction du rendu visuel (.texte-bleu) mais plutôt par rapport à sa fonction (.resume) ;
  • l’imbrication excessive de balises non sémantiques comme div ou span et l’abus de classes ;
  • utiliser la cascade pour cibler précisément un élément (#nav h2) ;
  • etc.

Si ces pratiques ont fait beaucoup de bien, notamment à une époque où les intégrateurs commençaient à adopter CSS, nous constatons aujourd’hui après plusieurs années d’expérience qu’appliquer ces préceptes à la lettre n’est pas sans effet de bord sur la maintenabilité du code.

Note importante : le propos qui suit s’adresse justement aux personnes qui ont acquis ces bonnes pratiques.

Les problèmes pratiques posés par cette théorie trop bien appliquée

Des CSS trop spécifiques, peu flexibles, peu prédictives

Dans le cas idéal - mais désormais rare - où la personne qui s’occupe de la CSS, celle qui s’occupe de la structure et celle qui gère les contenus ne font qu’une seule personne, il est possible d’espérer des problèmes dont la portée sera limitée… et pourtant, même dans ce cas en l’apparence simple, c’est très loin d’être aussi idyllique !

Plutôt qu’un long discours, prenons un exemple : supposons qu’un bloc d’informations soit sur une page donnée. D’après la structure qui a été définie dans les maquettes du site, ce bloc doit être unique. La première idée est de lui attribuer un id avec un nom qui a du sens (id="bloc-informations"), et donc de le styler via #bloc-informations. Sur le papier, l’approche n’est pas fausse.

Supposons que le site évolue, et qu’il faille dupliquer ce bloc, car le site a besoin d’une autre zone avec le même style mais dédiée à des promotions.

En supposant que l’intégrateur ait choisi d’utiliser une classe, il est possible de dupliquer le bloc. Toutefois la solution peut devenir problématique, car le projet va avoir plusieurs blocs dont la classe supposée sémantique peut… totalement perdre son sens.

Imaginons qu’il faille légèrement adapter le contenu de ce bloc, le projet se retrouve avec des styles trop spécifiques, et donc difficilement réutilisables.

Il faudra donc souvent redéfinir des styles. Un premier réflexe serait de se dire : surchargeons juste ce qui ne fonctionne pas comme souhaité, et le problème sera résolu !

Effectivement, le problème sera résolu… pendant un temps donné.

Des problèmes de surcharge

Supposons qu’il faille adapter le même bloc dans plusieurs autres cas. La surcharge, qui permettait d’adapter à peu de frais, risque de devenir de plus en plus complexe.
Toujours sur notre exemple, imaginons un autre cas de figure : un intervenant, pris par le temps, décide d’utiliser l’attribut !important sur une propriété, afin de rendre prioritaire le style qu’il ajoute. La surcharge devient excessivement dure, car la propriété qui utilise !important va devoir être surchargée par un sélecteur plus fort, lui-même utilisant !important.

Note : vous pouvez relire la cascade CSS pour comprendre les priorités des sélecteurs.

En résulte des sélecteurs qui deviennent longs, complexes et difficilement manœuvrables. Supposons maintenant qu’il faille ajouter une média-query pour adapter le contenu aux smartphones. Il faudra encore surcharger ces styles pour que la média-query, une fois ses conditions remplies, adapte les éléments en question. Etc.

Le problème est là, en pensant bien faire avec un postulat de base pourtant correct sur le papier, l’intégrateur a mis le projet dans un engrenage vicieux : les styles trop spécifiques ont mis en péril la qualité de l’intégration, qui est devenue difficilement réutilisable… et par extension, la qualité du site Web bien entendu.

Diversité des intervenants

Imaginons maintenant que ce projet fasse intervenir plusieurs personnes, de niveaux différents : ce qui peut paraître évident pour un intégrateur de haut niveau ne le sera pas forcément pour quelqu’un qui débute, ou même pour quelqu’un qui a un bon niveau mais qui est nouveau dans l’équipe. Si les CSS sont peu prédictives et complexes, la complexité et les problèmes vont croître de manière exponentielle avec le nombre d’intervenants.

La première conséquence de CSS peu réutilisables est de mobiliser les intégrateurs ayant le meilleur niveau pour des problèmes simples, les débutants n’arrivant plus à manœuvrer la CSS devenue trop complexe. Les intégrateurs de plus haut niveau seront donc mobilisés pour des problèmes qui ne devraient pas nécessiter un tel niveau d’expertise, provoquant une importante perte de temps et de productivité.

De plus, si des conventions de nommage n’ont pas été prises en amont, les divers intervenants ne se comprennent pas, chacun faisant à sa façon… la seconde conséquence est là : la CSS va vite devenir désorganisée et inconstante, pour le dire poliment.

Un léger problème de… surpoids !

À cause des problèmes énoncés ci-dessus (sélecteurs à rallonge, styles dupliqués, surcharge exagérée), les CSS vont prendre du poids.

Les sélecteurs trop longs et de nombreuses fois surchargés impactent également les performances. Malheureusement, le domaine de la performance Web est de plus en plus critique, notamment en situation de mobilité.

Plus le site comporte de déclarations de styles, plus ce problème va s’aggraver. Pire, c’est un cercle vicieux : plus les CSS sont lourdes, plus elles deviennent complexes. Plus elles sont complexes, plus elles sont difficiles à maintenir. Et plus elles sont difficiles à maintenir… plus elles s’alourdissent. C’est parfaitement illustré dans « Our best practices are killing us ».

D’autres pièges connexes

Les classes dites sémantiques sont censées renseigner le sens ou la fonction de l’élément auquel elles sont attribuées. Ce principe, comme il a été énoncé plus haut, peut poser des problèmes de ré-utilisabilité. Toutefois, posons-nous une question : à qui servent-elles réellement ? En tout cas, hormis dans le cas des microformats, l’internaute et son navigateur n’en ont cure : que les classes s’appellent .bloc-info, .pouet ou .kwzx, cela ne change rien pour l’affichage du site.

La croyance malheureusement bien installée qui explique que les classes doivent pouvoir renseigner à n’importe qui le sens… est non-sensique : les seules personnes potentiellement intéressées par ces noms de classes sont les concepteurs de sites ! Il faut donc avoir à l’esprit qu’en cas de différences notables d’implication et de niveau dans l’équipe dans un projet, les noms de classes doivent être aussi intuitifs que possible pour chaque intervenant.

Autant la sémantique de la structure ne souffre pas de discussion (un titre est un titre, une structure Hx doit être cohérente, etc.), autant la sémantique des classes peut être discutée et discutable.

Autre cas de figure, il a été coutume de cibler des éléments grâce à leur contexte, exemple #header h2 a. Notons que cela fonctionne, et ce n’est pas un hack. Néanmoins cela interdit de toucher à la structure, quelle que soit la raison, sans devoir également modifier la CSS.

Pour prendre une analogie [1] : quand un professeur appelle un élève, il ne dira pas « le second élève en partant du fond dans la rangée de droite », ce n’est pas pratique et ça ne peut pas servir dans une autre salle ou un autre cours.

Même si l’analogie prête à sourire, c’est pourtant ainsi que les CSS sont souvent construites ! Les conséquences restent les mêmes : problèmes potentiels de ré-utilisabilité, de maintenabilité, etc.

D’autres exemples classiques : il peut arriver qu’on vous demande de styler un titre de niveau 2, mais avec le style d’un titre de niveau 1. Comment faire si les styles se basent uniquement sur les balises (h2{}) ? Cibler des éléments via des balises peut être problématique, car ces balises peuvent être amenées… à être changées ou même détournées.

Beaucoup de pièges en l’apparence anodins

Rappelons-le : même si chacun de ces problèmes énoncés ci-dessus peut sembler anodin, c’est bien leur accumulation en « association de malfaiteurs » qui mène à des impasses très problématiques.

Ces nombreux problèmes que l’on peut rencontrer dans la pratique de l’intégration CSS, et ce dans des cas de figure très différents (équipe restreinte ou importante, projets de tailles diverses, etc.) apparaissent en respectant pourtant à la lettre les grands principes.

C’est qu’en les respectant à la lettre, on a oublié un point encore plus fondamental : le pragmatisme.

Soyons pragmatiques

Attention : il n’est pas question de dire que les précédents préceptes donnés ci-dessus sont à jeter aux oubliettes ! Ces principes restent pour la plupart valables et servent même de base à la compréhension des choix de l’intégrateur. Toutefois, c’est l’utilisation qui en est faite qui doit s’adapter et trouver un nouvel équilibre.

Il est capital de comprendre que cette notion d’équilibre est primordiale. Nous sommes dans un contexte de devoir produire des intégrations de qualité tout en ayant de nombreuses contraintes (et même de plus en plus de contraintes) :

  • une équipe avec des intervenants de différents niveaux,
  • des délais à tenir,
  • des besoins de souplesse et de ré-utilisabilité,
  • une prévisibilité de la CSS,
  • des performances satisfaisantes,
  • etc.

Si ces préceptes posaient des problèmes du fait d’une application trop rigoureuse, les recommandations ci-dessous sont dans le même cas : elles restent des conseils à replacer et adapter à votre contexte.

Limitation de l’utilisation des id au profit des classes

Côté structure, les id sont à utiliser avec plus de parcimonie qu’auparavant, on leur préférera les classes qui par principe sont plus réutilisables. Ils seront réservés aux éléments de structure qui sont de facto uniques : à priori un entête et un pied de page ne risquent pas d’être dupliqués.

Toutefois, il n’est pas question de prétendre que les id sont à proscrire dans la structure ! Ils ont d’autres utilités propres à cette dernière :

  • permettre des ancres internes (comme les liens d’évitement),
  • permettre divers aspects d’accessibilité des sites, par exemple, lier les label aux id des champs dans les formulaires, etc.,
  • offrir des possibilités de ciblage précis et rapide pour le JavaScript,
  • etc.

Donc, même si les identifiants sont présents dans le HTML, il vaut mieux cibler à l’aide de classes pour pouvoir plus facilement surcharger ces sélecteurs et leur donner une portée moins limitée.

Classes réutilisables et pratiques

Les classes dites sémantiques peuvent présenter l’inconvénient d’être trop spécifiques et peu réutilisables. On veillera à garder un sens quand c’est possible, toutefois, le précepte d’interdire des classes non sémantiques est à reconsidérer : si, comme nous l’avons dit plus haut, le sens des classes intéresse surtout les concepteurs de sites, alors des classes purement utilitaires (non sémantiques) peuvent apporter un plus pour la compréhension et le côté pratique au sein de l’équipe.

Leur sens sera totalement immédiat (surtout pour les personnes ayant le niveau le moins élevé en intégration dans l’équipe), et, utilisées à bon escient, elles éviteront de redéfinir des styles. De nombreux frameworks ont déjà franchi le pas, en proposant des classes utilitaires comme .left (pour un flottant), .w960p (pour une largeur de 960 pixels), etc.

Toujours dans la même optique, Nicole Sullivan propose une approche orientée objet des CSS : Object-Oriented CSS. Les deux principes sont les suivants :

  • utiliser des classes CSS indépendamment de la structure HTML (ce qui implique de nombreuses classes dans la structure),
  • et séparer le contenant du contenu (séparer les styles de positionnement d’un bloc de ceux des contenus du même bloc).

Par contre, ces classes utilisées en nombre sur un élément risquent de hérisser les cheveux des personnes qui exècrent la « classite » (les classes en nombre dans la structure). Ceci dit, sur un site conséquent avec une CSS complexe, la ré-utilisabilité et le poids de la CSS doivent primer : faire évoluer la structure avec une CSS prédictive, saine et réutilisable est dans de nombreux cas plus facile et moins consommateur de ressources que d’intervenir directement sur la CSS, et de la complexifier inutilement.

Des sélecteurs plus directs, indépendants de la structure et plus simples

Comme la structure sera amenée à évoluer, il peut être problématique de cibler certains éléments par leur balise, cette dernière pouvant changer et prendre la CSS en défaut.

Toujours dans la même optique, il faut éviter de cibler uniquement en fonction du voisinage, ce dernier pouvant totalement changer.

Par exemple, à la place de #footer blockquote, on préféra .citation.

La conséquence directe de ces constats est de devoir nommer chaque élément dans la structure afin de le cibler de la manière la plus courte et directe dans la CSS.

Autre point, il est plus que conseillé de s’interdire l’utilisation de l’attribut !important. Idéalement, bannissez-le de vos intégrations ou utilisez-le avec extrêmement de parcimonie.

Des sélecteurs courts sont plus performants, plus simples à manier, et dans le cas d’un besoin de surcharge (pour un design responsive par exemple), sont plus simples à surcharger. Plus la surcharge utilise des sélecteurs courts et efficaces, plus elle sera… performante !

Pour des terminaux mobiles, ce facteur sera particulièrement appréciable, même sans une approche plus radicale de type mobile-first.

Adopter des conventions de codage

Les syntaxes de CSS et d’HTML étant par nature plus permissives que celles de langages informatiques plus classiques (où la moindre erreur de syntaxe affiche une erreur d’exécution), les feuilles de style sont parfois complètement désorganisées et écrites de manière disparate.

Or on ne peut prétendre faire des CSS soignées et robustes sans avoir fixé des conventions, il n’est pas professionnel de produire une CSS complètement hétéroclite en laissant le soin à la minification et à la compression GZIP/DEFLATE de cacher la misère sous le tapis !

En voici un exemple : Idiomatic CSS, une proposition de convention pour CSS.

Bien évidemment, ce n’est qu’un exemple, d’autres conventions peuvent être utilisées, l’essentiel étant surtout… d’en choisir une et de s’y tenir avec la plus grande rigueur.

Conclusion

Comme toujours avec tout dogme, on s’aperçoit que le suivre sans réfléchir apporte son lot de problèmes, l’intégration CSS ne fait pas exception. L’évolution du métier, des demandes et de ses pratiques implique une mise à jour et une vigilance constantes.

Un des enjeux du développeur front-end éclairé de demain (et d’après-demain) sera de savoir repérer ce qui est plus important au cas par cas : appliquer la règle à la lettre, ou être pragmatique.

Références et compléments

Une fois de plus, nous vous invitons à lire ces compléments qui détaillent les concepts énoncés ci-dessus.

Notes

À propos de cet article

  • Openweb.eu.org
  • Profil : Expert
  • Technologie : CSS
  • Thème : Industrialisation, Méthodes, Qualité
  • Auteur :
  • Publié le :
  • Mise à jour : 24 septembre 2013
  • 11 commentaires

Vos commentaires

  • muchos Le 23 décembre 2012 à 02:23

    Merci pour ces réflexions.
    Pour ma part, j’ai encore des problèmes avec des noms de variables trop longs (surtout qu’ils fonctionnent en cascade et héritent du parent !), et avec les id trop utilisés au détriment de classes, et qui me poussent à faire des styles genre : #id-a, #id-b {style}

  • kami Le 25 décembre 2012 à 17:04

    Bonjour
    Article très intéressant. Dans les ressources j’ajouterais un article un peu long, en cours de traduction pour Pompage, intitulé Architecture CSS : http://engineering.appfolio.com/2012/11/16/css-architecture/
    Il détaille bien l’importance de produire des CSS prédictibles, réutilisables, maintenables et évolutives.

  • Nicolas Hoffmann Le 1er janvier 2013 à 09:43

    Kami : effectivement, un très bon article que voilà, merci ! :)

  • BeliG Le 2 janvier 2013 à 10:19

    Salut,

    Nicole Sullivan propose une approche orientée objet des CSS : Object-Oriented CSS. Les deux principes sont les suivants :
     manipuler les classes CSS indépendamment de la structure HTML,
     séparer le contenant du contenu.

    Les 2 principes du CSSOO sont en réalité de :
     Séparer la structure de l’aspect visuel (= on utilise les classes CSS comme des "objets modulables", exemple avec un ".box" qui engloberait tous les styles cosmétiques d’un modèle de boite : bordure, ombre portée, background, etc.)
     Séparer le contenu du contenant (= le but étant de manipuler ces objets indépendamment de leur structure HTML, exemple ".title" qu’on pourrait utiliser sur un <h1>, <h2>, ...)

    Donc :
    1 - Quand tu copies une source, un minimum de respect impliquerait de citer celle-ci en référence.
    2 - Avant de recopier (mal), il faut comprendre (bien).

    Bonne année. :)

  • Nicolas Hoffmann Le 4 janvier 2013 à 09:25

    Belig : certes, je l’ai formulé différemment, et je reconnais que ça peut induire en erreur (j’ai d’ailleurs changé la première phrase). Donc, merci de l’avoir re-expliqué en commentaire. :)

    Toutefois :

    1 - un minimum de respect : quand tu cites une source, cite-la correctement, j’ai ajouté quelques détails entre parenthèses afin de préciser ma reformulation, et aussi imparfaite soit-elle, les omettre change totalement le sens de cette reformulation.

    2- je t’invite à mieux lire les références, il y a un lien nommé "Object-Oriented CSS". Donc avant de citer (mal), il faut lire (bien).

    Bonne année ! :)

  • BeliG Le 4 janvier 2013 à 12:26

    @Nicolas Hoffmann :

    Il y a méprise, je ne parlais pas de la référence à "Object-Oriented CSS", mais d’un article que j’ai écrit il y a plus d’un an, où on peut trouver notamment :

    Le but du CSSOO est de manipuler les classes CSS comme des objets à part entière, indépendamment de leur structure HTML. C’est ce que Nicole Sullivan entend dans sa présentation par « Séparer le contenu du contenant ».

    En comparant avec ce que tu as écrit précédemment :

    manipuler les classes CSS indépendamment de la structure HTML,
    séparer le contenant du contenu.

    Si c’est une coïncidence, alors elle est collector :)

  • Nicolas Hoffmann Le 5 janvier 2013 à 09:05

    Ah, quand on m’explique le fin mot, je comprends mieux. Et bien... c’est une coïncidence collector, car je n’avais jamais lu ton article. :)

  • UnSeulT Le 7 janvier 2013 à 17:24

    Pour ce qui est de l’utilité des id, on peut enlever le point "offrir des possibilités de ciblage précis et rapide pour le JavaScript" en utilisant à cette fin les attributs data-* très pratiques :)

    En tout cas, vive le pragmatisme, c’est clair !

  • Camille Le 10 avril 2013 à 23:21

    Les CSS commencent à être de plus en plus gros, mais bon en soit ça reste pas trop lourd.

  • Frank Taillandier Le 10 juin 2013 à 15:14

    Le truc important c’est de pas trop lier le nom des classes CSS aux contenus, et ça on l’a tous fait depuis le début - c’est même fait dans l’article (.resume). C’est ce qui rend les classes de styles réutilisables. Idéalement on devrait pouvoir modifier l’apparence sans toucher au HTML (ou alors juste aux classes). Mais bon ce niveau d’abstraction est issu de réflexions liés à de gros sites comme Facebook ou Twitter, comme toute chose, c’est à relativiser et à adapter à son propre cas de figure.

    Et donc en cours de traduction pour http://pompage.net, les réflexions de Nicolas Gallagher sur l’architecture front qui s’inspirent de BEM (qui lui même a du s’inspirer d’OOCSS) : http://nicolasgallagher.com/about-html-semantics-front-end-architecture/

  • erwan21a Le 16 juin 2015 à 15:25

    Bonjour,

    Rapide présentation :
    J’ai appris à coder le CSS il y a environ 4 ans et demi. Depuis trois ans, je suis web designer pour un gros/lourd site internet où je programme en Less dans un univers Microsoft .NET. Cette entreprise m’a laissé mettre en place ma propre vision de l’organisation des styles avec la performance comme unique jugement. Travailler entouré d’ingénieurs informatiques à forcément influencé ma pratique et ma vision des choses. Depuis un an, je commence à confronter mon expérience à ce qui se fait ailleurs - notamment aux frameworks - et je me rend compte que je suis allé dans la même direction (plutôt bon signe).

    Il me semble important dans un premier temps d’évoquer les différentes manières de produire une page web. Les contraintes de production d’une page issue directement d’un fichier HTML seront très différentes d’une page générée par un CMS ou provenant d’un architecture MVC par exemple. La finalité est la même mais pas les besoins en production. Or, là on parle de production.

    Une page web peut résulter de l’association d’une dizaine de fichiers écrient en différents langages. Avec une strict application du nommage descriptif, une volonté de changer d’apparence nécessiterait la mobilisation de nombreux ingénieurs (taux horaire fort) pour que chacun passe en revue le code qu’il génère pour fabriquer la page finale.

    Il faut bien comprendre que les Frameworks CSS, ayant ré-enclanchés ces questionnements, sont globalement prévus pour une logique d’agence. Création d’un HTML neuf + un Framework CSS = un site. Hop, emballé c’est pesé !
    Dans un contexte "chez l’annonceur", certaines pages peuvent avoir nécessitées un lourd développement pour produire le HTML (généré par divers langages). Ce qui est facilement évolutif et à coût maîtrisé, c’est donc le CSS.

    Cela ne veut pas dire pour autant qu’il ne faut rien faire, rien changer.
    Mais l’emballement actuel à renier tous les principes d’antan est aussi excessif que leur application rigoureuse.
    Un compromis structurel est encore à trouver afin de répondre à tous types de cas de la meilleures des manières.

    Erwan.

Vos commentaires

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?
Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom