CSS, le mal-aimé… et pourtant, que ferais-je sans toi ?

Cette citation m’a interpellée, en tant que CSS Loveuse depuis que j’ai commencé à faire du développement front-end. Avec l’évolution de notre métier ces dernières années, j’ai constaté autour de moi, d’un côté la montée fulgurante du JavaScript et des frameworks JS/CSS auprès de la communauté, et de l’autre côté, un délaissement du langage pur CSS malgré son évolution constante et son importance au sein du web. CSS n’obtient plus l’amour qu’il mérite pourtant, parmi la foule de développeurs et de développeuses :

C’est bien dommage… car le CSS c’est l’ingrédient principal de notre gâteau, l’interface. C’est ce qui a aussi forgé notre métier, tout est parti de là.

Alors pourquoi ce retournement de situation ?

Aux origines

Impossible de parler CSS sans évoquer son fidèle partenaire, HTML.

L’idée principale du HTML était de présenter des informations d’une manière simple, qui était au départ destinée au partage de documents scientifiques et d’articles de recherche en ligne. Cependant, au fur et à mesure qu’Internet se développait, le rôle du HTML a été amplifié et ce dernier a été finalement utilisé pour la présentation Web. Le seul hic, c’est qu’il y avait quelques problèmes de formatage. C’est à ce moment-là que CSS est entré en jeu. La volonté du norvégien Håkon Wium Lie, en 1994, de créer une feuille de style standardisée universelle pour le Web, y a contribué.

Les travaux du World Wide Web Consortium (W3C) sont devenus des recommandations sous le nom de CSS1 en 1996, CSS2 en 1998, CSS2.1 en 2011 — et la gestion de CSS3 en modules indépendants est évoquée dès 2001, avec les premiers modules de niveau 3. Quand à la suite, NON désolée, il n’a pas de CSS4 ! Leur nouvelle stratégie est de travailler sur les modules séparément, pour les intégrer et les faire évoluer au cas par cas.

Quand j’imagine que l’on est passé de ce type de page :

à ceci en 2022 :

J’ai juste envie de dire : « Merci ! » à l’équipe de création de CSS.

La folie des frameworks CSS

L’arrivée des frameworks a changé la donne dans le processus de développement. Les besoins ont évolué. Vitesse, uniformité, efficacité, sont devenus les maîtres-mots. Comment ? En fournissant un ensemble d’outils de classes CSS prédéfinies qui peuvent être utilisés pour créer des pages. De cette manière, nous, développeurs et développeuses, n’avons pas à commencer à intégrer « from scratch » (de zéro) le style CSS des pages à partir d’une page blanche. Nous avons une base sur laquelle s’appuyer.

Exemple (extrait de Bootstrap) :

  
    <div class="row no-gutters">
      <div class="col-12 col-sm-6 col-md-8">.col-12 .col-sm-6 .col-md-8</div>
      <div class="col-6 col-md-4">.col-6 .col-md-4</div>
    </div>
  

Ici :

• La classe no-gutters permet de supprimer les margin et les padding dans un bloc ;
• Les classes préfixées par col- correspondent aux tailles définies pour les colonnes d’une grille.

Cependant, je tiens à rappeler pourquoi les frameworks ont été créés à la base : c’était pour permettre à des personnes qui ne maîtrisent pas le langage CSS de réaliser la mise en page sans avoir à faire trop de manipulations dans le code.

Bootstrap a fait partie des premiers à lancer le mouvement. L’idée de mettre en place un outil qui permet de tout styliser sans ajouter une seule ligne de CSS, c’était fort ! D’autres frameworks ont suivi depuis.

Un autre point à soulever aussi, c’est qu’il faut se rendre compte de ce qui se passe dans la réalité dans un projet web. Dans certains cas, ce sont des développeurs et des développeuses back-end qui se retrouvent dans une position où ils doivent faire du front-end. Ils ne sont pas forcément à l’aise avec CSS et toutes ses subtilités, mais ils savent s’appuyer sur une documentation qui leur indique comment intégrer le style d’un bouton ou d’une modale par exemple.

Alors oui, l’idée de base est bien noble. Cependant, cela soulève des constatations :

• La facilité d’accès et d’utilisation des ces frameworks n’incitent pas forcément les développeurs et développeuses à creuser l’apprentissage et la maîtrise des concepts liés au CSS lorsque l’on n’est pas initié ;
• Il sera difficile pour le développeur ou la développeuse d’implémenter le CSS lorsque les frameworks CSS ne seront pas une option.

Voici venu le temps de la frustration

J’ai souvent vu ce gif passer sur les réseaux. Et la plupart du temps, la personne qui a posté cette image obtient une vingtaine de likes. Succès garanti !

Mais creusons un peu plus loin. Que s’est t‑il donc passé ? Un des scénarios possibles. Le développeur ou la développeuse a tenté de changer un élément dans son CSS et :

1. Un autre élément qui semble non lié a été impacté. Les effets de bord deviennent incontrôlables ;
2. Rien ne se passe.

C’est à ce moment-là qu’on n’est plus en phase avec CSS. C’est l’incompréhension, la colère devant son écran, l’abandon.

Les causes les plus courantes

• Les sélecteurs mal formés qui ne « trouvent » pas les bons éléments ;
• Les conflits avec d’autres feuilles de style, surtout lorsque l’on n’a aucun contrôle sur l’ordre de chargement. Et ils peuvent être nombreux :
  • Les styles de navigateur par défaut ;
  • Les styles de l’auteur ou de l’autrice ;
  • Les styles tiers associés aux bibliothèques ;
• L’utilisation de la mention !important, qui va surcharger une déclaration CSS pour outrepasser la déclaration CSS principale ayant le plus gros poids ;
• Les propriétés de haut niveau sont parfois ignorées en faveur de sélecteurs de niveau inférieur, plus spécifiques, tels que les combinaisons ID/classe, les classes multiples, les paramètres d’élément (par exemple les attributs [type=""] ou [attr=""]), etc.

CSS est un langage déclaratif et non procédural

La plupart des développeurs et des développeuses ont commencé leur carrière en apprenant le légendaire « Hello world ! ». Le principe est simple : on code une instruction, on l’exécute et elle affiche la chose exacte. Ce n’est pas le cas du CSS déclaratif basé sur des règles. On manipule l’apparence et parfois le comportement d’une page en déclarant un ensemble de règles. Et c’est là que les ennuis commencent pour beaucoup d’entre nous.

Des centaines voire des milliers de règles peuvent être ainsi définies par le développeur ou la développeuse. Celles-ci peuvent se chevaucher ou se contredire. Ainsi, toutes les règles spécifiées doivent être traitées et harmonisées selon les principes dits de cascade.

Il existe de nombreuses autres raisons pour lesquelles CSS peut être frustrant, mais c’est plus une question de recherche et d’apprentissage.

Je pense que les deux éléments qui rendent le CSS plus difficile à apprendre sont la cascade et la spécificité. La grande majorité des personnes que j’ai croisées qui sont frustrés par le CSS n’ont pas tout à fait compris ses concepts.

Enfin, où en serions-nous sans CSS ?

Peut-être que la meilleure façon de décrire cela est de montrer ce qu’une page serait si CSS n’existait pas.

Le Web tel que nous le connaissons aujourd’hui ne pourrait pas exister sans CSS. Une analogie couramment utilisée est celle de la construction d’une maison. Bien que l’on puisse construire une maison en utilisant uniquement des briques (HTML), elle n’aurait aucune fonctionnalité. Ainsi, pas de couleur sur les murs, de décoration, d’architecture intéressante et d’effets visuels.

Sans CSS, les pages Web sont simples et loin d’être inspirantes. Elles seraient affichées de manière brute.

En tant que développeuse front-end, je crée ce que l’utilisateur voit. Et ce que l’utilisateur voit est défini en partie par CSS. Immanquablement, un développeur ou une développeuse front-end sera régulièrement en contact avec le CSS. C’est dans les gènes.

Le fait est qu’aujourd’hui, si vous détestez CSS, demain vous détesterez un autre langage dont l’apprentissage sera un besoin.

Alors au lieu de lui fermer la porte au nez, embrassez CSS et faites-en votre nouvel ami.

Ressources :

• A brief history of CSS until 2016 ;
• MSHP 1994 ;
• Bootstrap : Introduction.