Raphaël Goetter a écrit un billet sur son blog que je ne peux que recommander d'aller lire : CSS, la grande remise en question. Cela m'inspire plusieurs réflexions.
Une des grosses faiblesses de CSS, enfin jusqu'à présent, est d'avoir été majoritairement promulgué par des gens dont ce n'est pas la spécialité, au sens de devoir produire de la CSS. Beaucoup. Tous les jours.
En résulte quelques dogmes qui, s'ils ont réellement fait du bien quand il a fallu se débarrasser des tableaux de présentations, posent maintenant des problèmes si on les applique trop strictement.
La sacro-sainte sémantique est l'un des piliers. Seulement, si je peux comprendre qu'une structure HTML soit sémantique (un titre est un titre, etc.), c'est quoi une classe CSS sémantique ?
Donc, il faudrait que les noms de classes soient explicites et aient du sens. Seulement, à qui cela profite ?
- Aux navigateurs ? Sauf votre respect, si la classe s'appelle
.aou.totoou.bloc_info_news, le navigateur s'en fout. - Aux utilisateurs ? Ils s'en foutent encore plus, tant que le site marche.
- Aux intégrateurs ? Ah oui, là c'est utile : il faut que les classes sont intelligibles pour les personnes qui vont s'en servir.
Seulement à votre avis, vous pensez qu'un intégrateur qui arrive sur le projet et/ou qui débute va mieux comprendre .left ou .bloc_info_aside_events ? Donc, déjà pour moi, l'emploi de certaines classes génériques n'est même pas sujet à débat, c'est une nécessité pratique.
Quand vous maintenez une unique CSS qui gère un très gros site, je peux vous assurer que si vous utilisez des styles peu réutilisables, votre CSS va enfler littéralement et va vite devenir difficile à maintenir.
D'autres domaines suggèrent des pratiques qui servent la réutilisabilité. Typiquement, quand on parle performances, un des conseils est d'éviter les sélecteurs à rallonge. C'est extrêmement pratique pour la réutilisabilité et pour les versions mobiles et/ou imprimables, cela évite d'avoir à surcharger des styles à rallonge avec des styles encore plus à rallonge, et surtout d'avoir à redéfinir des styles trop spécifiques. C'est principalement pour cela que j'ai dans mes CSS des sélecteurs très courts.
Encore une fois, tout n'est pas à jeter dans les anciens préceptes, bien au contraire. Mais les contraintes du métier ont réellement évolué, ne faites surtout pas l'erreur de croire que vous n'avez pas besoin d'évoluer avec. Sans parler de grande remise en question, le métier change. Même en faisant mes CSS presque tout seul sur certains projets, d'autres intervenants qui mettent le contenu me font changer ma façon d'aborder le côté pratique des styles que je définis. Alors, imaginez sur des projets bien plus énormes.
Et pour terminer, une question : en matière de CSS, va-t-on enfin écouter ceux dont c'est le métier ?
Lisez donc des articles de Raphaël Goetter ou l'excellent livre CSS maintenables de Kaelig, vous aurez une approche bien moins dogmatique et beaucoup plus professionnelle du métier.
J'ai lu le billet de Raphaël et pense que les bonnes pratiques d'intégration web / CSS devraient se conformer à ce qui existe dans les domaines connexes. En effet, qu'ils s'agisse des méthodes de développement informatique ou même de structuration de code HTML, les outils et les normes existent (je pense à Opquast pour les bonnes pratiques, à KNACSS pour le canvas, à TopStyle et autres pour les environnements de code).
Mettre en application ces principes en utilisant ces outils permet déjà de partir sur une bonne base non ?