Il y a quelque chose qui me dérange quand une nouvelle approche de CSS arrive, c’est que souvent la démonstration commence par poser le postulat que l’approche est géniale, ensuite elle démontre pourquoi elle est géniale, et enfin elle conclut qu’elle… est géniale – entre nous soit dit, beaucoup de « démonstrations » fonctionnent ainsi (et c’est accentué par les posts hautement argumentés que l’on peut faire sur Twitter… en 140 caractères donc).

Évidemment, sur mon esprit cartésien, ce genre de « démonstration » n’a que très peu d’effet.

Même si l’approche peut effectivement avoir de grands avantages, je préfère quand la démonstration part des problèmes donnés, se construit, montre ses conditions limites (important ce point, malheureusement trop souvent oublié), conclut sur ses avantages et enfin laisse aux lecteurs le plaisir d’en déduire si elle est géniale.

Souvent, quand je tombe sur ces nouveautés, je m’amuse à les tester, mais pas de manière brutale, de manière beaucoup plus progressive. Ainsi, je peux refaire le chemin de la réflexion, la pondérer, l’apprécier, l’infirmer ou la confirmer.

Un exemple : il y a quelques années, cela faisait un moment que bon nombre de tweets et billets martelaient qu’il ne fallait jamais utiliser d’id pour cibler un élément en CSS. Je passe sur les arguments qui disaient « c’est mal » sans aller plus loin et sur les arguments absolument débiles genre « c’est pas beau », les seuls arguments me semblant corrects étaient les suivants :

• il n’est pas réutilisable ;
• le poids est trop élevé par rapport aux classes.

Le premier argument n’était pas nouveau, c’est la définition même de l’id : il est unique. Le second méritait de s’y pencher.

Avec mon esprit de contradiction, je me suis dit : pourquoi poser comme postulat que le poids fort de l’id en CSS soit un inconvénient, alors qu’on pourrait tout simplement en tirer avantage ? Ma première idée était d’utiliser les classes pour styler, et le poids de l’id par exemple pour surcharger à coup sûr les propriétés dans une media-query pour mobile. Et figurez-vous… que ça marchait super bien ! Cela permettait de surcharger efficacement à peu près n’importe quoi avec un sélecteur court.

Sauf qu’en fait, cela marchait bien si on n’avait à effectuer que très peu de surcharges, une ou deux maximum, et surtout si l’on avait besoin de surcharger des sélecteurs avec un nombre de classes à rallonge (ce qui n’est pas bien, les performances déconseillent des sélecteurs trop longs). Sur des sites simples, ça fonctionnait bien (je me souviens l’avoir fait sur un ou deux sites), mais dès que cela se compliquait un peu, je me retrouvait à me trimballer soit des id à surcharger, soit à le faire sur les classes. Plus gênant, les id m’empêchaient même d’utiliser certaines classes utilitaires de RÖCSSTI.

Or, l’ordre dans RÖCSSTI a toute son importance : d’abord les propriétés générales, ensuite le layout global, ensuite le spécifique. Et idem dans les media-queries (ce qui facilite grandement la surcharge). Or là, l’utilisation un peu hasardeuse des id dans la CSS vient au mieux permettre ce qu’une classe bien utilisée permettait déjà, au pire gêner un des principes les plus importants de CSS : du plus général au plus spécifique.

Bref, en quelques essais, je m’aperçus que dans certains cas mon idée fonctionnait, qu’elle n’était pas fondamentalement mauvaise (elle n’a pas empêché certains sites de fonctionner), mais qu’elle dérangeait dans beaucoup d’autres. Par contre, je constatais en même temps que fonctionner avec des classes ne gênait pas : en fait tout le monde a le même poids, et c’est l’ordre de déclaration qui dicte le résultat final. Au final, un principe de base de CSS se retrouve mis en avant, et ça c’est plutôt un bon indicateur.

Bref, tout cela pour vous rappeler un principe : ayez vraiment l’esprit critique face à des articles de plus en plus percutants et des effets de mode : testez, évaluez, appropriez-vous, pondérez, etc. Non pas qu’il faille partir de l’idée que tout changement est à éviter, mais qu’il faut surtout en tirer la substantifique moelle comme disait Rabelais.

Je me permets de re-citer (oui, je le fais souvent) Mehdi Kabab dans un commentaire sur 24 jours de Web :

Intégrateurs, votre cœur de métier ne se limite pas à pisser du CSS au kilomètre. Vos compétences et le savoir que vous avez acquis à la sueur de vos erreurs (vive l’apprentissage par l’échec, la meilleure école de l’intégrateur/développeur Web) ont de la valeur. Alors, s’il vous plaît, ne les rejetez pas sous prétexte qu’un personnage influent clame tout haut une opinion personnelle, mais qui se répand comme une traînée de poudre de part son statut de « gourou ».

Et avant que cela ne trolle violemment dans les commentaires : avoir l’esprit critique n’empêche pas de tester comme un dingue et d’évoluer à vitesse grand V : je ne fais pas un site sans qu’il y ait un truc de nouveau, mieux, amélioré. Non pas que le site sera forcément mieux que le précédent, mais comme principe de base, il faut que j'améliore au moins un point dans chaque réalisation par rapport à la précédente !