Pourquoi il n'aurait pas du arrêter d'utiliser CSS
By glazou on Saturday 18 June 2016, 18:40 - CSS and style - Permalink
Cet article est un commentaire sur celui-ci. Je l'ai trouvé via un tweet de Korben, évidemment. Il m'a un peu hérissé le poil, évidemment, et donc j'ai besoin de fournir une réponse à son auteur via ce blog.
Les sélecteurs
L'auteur de l'article fait les trois reproches suivants aux sélecteurs CSS :
- La définition d'un style associé à un sélecteur peut être redéfinie ailleurs
- Si on associe plusieurs styles à un sélecteur, les derniers définis dans le CSS auront toujours la priorité
- Quelqu'un peut péter les styles d'un composant pour peu qu'il ne sache pas qu'un sélecteur est utilisé ailleurs
Le moins que l'on puisse dire est j'ai halluciné en lisant cela. Quelques lignes au-dessus, l'auteur faisait une comparaison avec JavaScript. Reprenons donc ses trois griefs....
Pour le numéro 1, il râle parce que if (foo) { a = 1; } ... if (foo) { a = 2;} est tout simplement possible. Bwarf.
Dans le cas numéro 2, il râle parce que dans if (foo) { a = 1; a = 2; ... } les ... verront la variable a avoir la valeur 2.
Dans le cas numéro 3, oui, certes, je ne connais pas de langage dans lequel quelqu'un qui modifie sans connaître le contexte ne fera aucune connerie...
La spécificité
Le « plein délire » de !important, et je suis le premier à reconnaître que cela ne m'a pas aidé dans l'implémentation de BlueGriffon, c'est quand même ce qui a permis à des tétraflopées de bookmarklets et de codes injectés dans des pages totalement arbitraires d'avoir un résultat visuel garanti. L'auteur ne râle pas seulement contre la spécificité et son calcul mais aussi sur la possibilité d'avoir une base contextuelle pour l'application d'une règle. Il a en partie raison, et j'avais moi-même il y a longtemps proposé un CSS Editing Profile limitant les sélecteurs utilisés dans un tel profil pour une plus grande facilité de manipulation. Mais là où il a tort, c'est que des zillions de sites professionnels utilisant des composants ont absolument besoin des sélecteurs complexes et de ce calcul de spécificité...
Les régressions
En lisant cette section, j'ai laché un sonore « il exagère tout de même »... Oui, dans tout langage interprété ou compilé, modifier un truc quelque part sans tenir compte du reste peut avoir des effets de bords négatifs. Son exemple est exactement conforme à celui d'une classe qu'on dériverait ; un ajout à la classe de base se retrouverait dans la classe dérivée. Oh bah c'est pas bien ça... Soyons sérieux une seconde svp.
Le choix de priorisation des styles
Là, clairement, l'auteur n'a pas compris un truc fondamental dans les navigateurs Web et le DOM et l'application des CSS. Il n'y a que deux choix possibles : soit on utilise l'ordre du document tree, soit on utilise des règles de cascade des feuilles de styles. Du point de vue du DOM, class="red blue" et class="blue red" sont strictement équivalents et il n'y a aucune, je répète aucune, garantie que les navigateurs préservent cet ordre dans leur DOMTokenList.
Le futur de CSS
Revenons à la comparaison JS de l'auteur. En gros, si on a en ligne 1 var a=1 en ligne 2 alert(a), l'auteur râle parce que si on insère var a = 2 entre les deux lignes on affichera la valeur 2 et pas 1... C'est clairement inadmissible (au sens de pas acceptable) comme argument.
La méthodologie BEM
Un pansement sur une jambe de bois... On ne change rien mais on fout des indentations qui augmentent la taille du fichier, gênent son édition et sa manipulation, et ne sont aucunement compréhensibles par une machine puisque tout cela n'est pas préservé par le CSS Object Model.
Sa proposition alternative
J'ai toussé à m'en éjecter les poumons du corps à la lecture de cette section. C'est une horreur non-maintenable, verbeuse et error-prone.
En conclusion...
Oui, CSS a des défauts de naissance. Je le reconnais bien volontiers. Et même des défauts d'adulte quand je vois certaines cochoncetés que le ShadowDOM veut nous faire mettre dans les Sélecteurs CSS. Mais ça, c'est un rouleau-compresseur pour écraser une mouche, une usine à gaz d'une magnitude rarement égalée.
Je ne suis globalement pas d'accord du tout avec bloodyowl, qui oublie trop facilement les immenses bénéfices que nous avons pu tirer de tout ce qu'il décrie dans son article. Des centaines de choses seraient impossibles sans tout ça. Alors oui, d'accord, la Cascade c'est un peu capillotracté. Mais on n'attrape pas des mouches avec du vinaigre et si le monde entier a adopté CSS (y compris le monde de l'édition qui vient pourtant de solutions assez radicalement différentes du Web), c'est bien parce que c'est bien et que ça marche.
En résumé, non CSS n'est pas « un langage horriblement dangereux ». Mais oui, si on laisse n'importe qui faire des ajouts n'importe comment dans un corpus existant, ça peut donner des catas. C'est pareil dans un langage de programmation, dans un livre, dans une thèse, dans de la mécanique, partout. Voilà voilà.
Comments
Merci beaucoup pour cette réponse, précise et factuelle.
C'est assez dingue de voir que là où le problème humain est clairement identifié comme source du problème, c'est le langage qui est pointé du doigt. La stack proposée alourdit un couple de base (HTML/CSS) qui fonctionne, tout ça pour s'assurer que le code généré en dernier ne viendra pas casser le précédent. Hmmm, ok, on a compris qu'il n'aime pas la mutation et que seules les constantes l'intéressent. Pour ce qui est du style inline, c'est vrai que dans une période où on cherche à alléger les pages et à cacher un maximum de choses pour améliorer la mobilité, intégrer des styles complexes partout est LA solution...
Un contexte de qualité, ça se crée et ça se pérennise sur la durée à l'aide de gens formés et au minimum au courant de l'historique du projet en cours. Les tests, les code review... Bref, merci pour cette mise au point que je ne peux que partager.
Le problème dans tout ça (si je met à part le fait que la plupart des arguments ici présent sont boiteux - eg le coup du a = 2 il faudrait comparer en plaçant la définition dans un autre fichier, inclu après le alert(a)) c'est que c'est bien gentil de dire: "écrire du CSS propre c'est facile".
Mais dans la réalité sur un projet où plusieurs dévs avec plus ou moins rigoureux, plus ou moins expérimenté où il y a peu ou pas de revues de code, peu ou pas de tests automatisés il est quasiment impossible de garder du CSS de qualité, scopé.
Donc si, CSS est dangereux à grand (ou même moyenne) échelle.
Au final c'est beaucoup plus pénible que d'ajouter des restrictions. Car oui les solutions pour écrire les styles via JavaScript existe principalement pour cette raison: scopé le CSS afin d'éviter les effets de bords...
Les réactions sur l'article initial me font bien rire, mais toutes les personnes qui s'affolent sont clairement déconnecté de la réalité des projets. Je suis freelance et sur tous les projets où je passe, les CSS sont plus bordélique que tous le reste de la stack réuni. Alors moi je m'en plaint pas, ça me fait du boulot. Mais faut arrêter de dire que "CSS c'est facile pour faire du code propre". Oui c'est facile, mais l'inverse l'est encore plus, et c'est bien ça le gros problème.
Amen !
J'avais jamais lu un article sur CSS aussi naze. On dirait que l'auteur vient de découvrir l'informatique et se dit "Ho la la, c'est dur quand même". S'il n'est pas capable de maintenir une feuille de style au point de vouloir anéantir CSS, il est mal barré pour un développeur front-end !
Merci de lui avoir répondu j'espère qu'il viendra vous lire.
J'ai eu à peu près la même réaction en le lisant et me suis dit "encore un petit nouveau qui se lance sur des explications d'une techno qu'il commence tout juste à maîtriser"
J'ai même failli pleurer en voyant la proposition alternative, je pense qu'il n'a aucune notion sur le fonctionnement des navigateurs, des caches, des domaines statics ...
Merci pour cette réponse éclairée :)
Pour rebondir sur le commentaire de Simounet, l'article de bloodyowl part en effet du postulat qu'on doit empêcher les autres intervenants de faire des bêtises avec le code.
Je trouve que c'est un cruel manque de confiance envers ses pairs, et une déresponsabilisation de l'auteur pour la formation de son entourage professionnel. Ils pourraient se blesser, alors autant ne pas leur apprendre à s'en servir du tout…
Bonjour,
je vous suis dans vos réponses, et je pense qu'elles sont justes,
mis à part sur la partie BEM où je n'ai tout simplement pas compris vos arguments.
Je serai ravi d'un complément d'information sur cette partie notamment ce qui concerne la préservation par le CSS Object Model.
Merci.
Merci pour cette réponse Daniel.
L'article de bloodyowl montre bien qu'il y a malheureusement peu de gens qui savent réellement faire du CSS. Je vois de gros projets réalisés par de grandes agences avec un CSS inmaintenable. La partie front est souvent négligée et dans beaucoup de projets il n'y a même pas de développeur front-end.
Ça confirme que faire du CSS ça ne s'improvise pas. C'est quasiment un métier à part, ça permet tellement de choses, que mal maîtrisé on en fait n'importe quoi. Un peu comme le JS.
@Zéfling : mais y'a plus de métier "improvisable" dans la babasse. Pour faire quoi que ce soit, il faut un niveau de compétences élevé et un informaticien reste un étudiant toute sa vie. Je ne vois absolument pas en quoi CSS diffère des autres technologies software.
Je viens de découvrir cette notation BEM, ça me fait penser à la tristement célèbre notation dite "Hongroise", enfin la variante où on ajoute en préfixe le type de la variable. Personnellement si je veux un simili espace de nom, j'utiliserai du simili nom de paquetage, par exemple "comSporniketWebComponentButton".