{"partition": "head_middle", "source_domain": "openweb.eu.org", "digest": "sha1:FNZ62XTENL7PGSLTG6KNEZBJEKOSHROH", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00027.parquet"}
Voir ailleurs
See this site in English
Décideur
Gourou
Industrialisation
Mise en page
Pages dynamiques
CSS, l’âge de raison
Openweb.eu.org > Articles > CSS, l’âge de raison
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.
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éeDes 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 p