CSS, la grande remise en question

La morale de ce (long) billet est qu’il faut parfois remettre en question ses a priori et préceptes établis et que CSS, comme le Web en général, est un concept vivant qui évolue. A nous d’évoluer avec lui.

—

Les 5 lois ancestrales de l’intégrateur, telles que je les ai subies et transmises :

1. Un code valide tu produiras (fermer les balises, utiliser les minuscules, etc.)
2. Les tableaux tu diaboliseras (et les spacer.gif aussi)
3. A la divite (et classite) tu ne t’exposeras point (ne pas ajouter d’élément HTML ou classes inutiles)
4. Aux sélecteurs CSS tu rendras gloire (les sélecteurs “avancés” permettent de cibler n’importe quel élément)
5. La Sainte Sémantique tu respecteras (toujours choisir les éléments et balises en fonction de leur sens)

Oui mais…

C’est “à cause” de ce genre de préceptes établis que l’on rencontre des aberrations sur de très gros sites en production.

Stoyan Stefanov avait fait quelques constats à propos du top 1000 Alexa (les 1000 plus gros sites du monde) :

• plus de 12% des gros sites ont plus de 50 fois “!important » dans la feuille de style
• plus de 13% des sites ont plus de 100 fois “float”
• plus de 25% des sites comportent plus de 100 fois l’instruction “font-size”
• enfin, le site Facebook à lui seul comporte… 261 valeurs de la couleur bleue dans ses feuilles de styles
• etc.

Ces répétitions et duplications multiples ne font pas qu’alourdir le code, elles le rendent également moins performant et surtout indigeste et difficile à maintenir.

Tout cela pour “respecter les règles”…

Par expérience, les impondérables rencontrés sur chaque projet web sont :

• Des délais à respecter
  il faut aller vite, être productif, s’adapter à des deadlines mouvantes
• Des intervenants multiples
  des experts CSS, mais aussi des novices, des développeurs, graphistes, chefs de projets
• Au secours, un nouveau !
  l’équipe évolue, la courbe d’apprentissage doit demeurer constante
• Un projet et ses specs évoluent toujours
  savoir produire un code cohérent, conventionné, souple et réutilisable

Depuis la nuit des temps, on a appris à faire des intégrations HTML / CSS “valides” et respectant les préceptes, mais… dans la vraie vie, les contraintes de production font que les intégrations doivent surtout être : rapides, maintenables, flexibles, prédictives, évolutives, réutilisables, compatibles, accessibles, performantes, etc. Bref : efficaces !

En clair, les contraintes de production ont évolué en 15 ans… mais pas nos techniques et préceptes d’intégration CSS.

CSS, ce n’est pas que pour des robots

OK, CSS c’est du code, c’est prévu pour être interprété par une machine.
Mais on oublie souvent qu’au final trois types d’interlocuteurs seront amenés à analyser votre page web :

• des machines (agents utilisateurs, navigateurs, moteurs de recherche)
• des visiteurs (clients, curieux)
• des collègues (intégrateur novices, experts, développeurs, graphistes), bref, des humains

Un code CSS doit évidemment être compréhensible, robuste et réutilisable pour les machines qui vont l’interpréter, mais aussi et surtout pour des êtres humains. Pour votre collègue ou votre successeur, un nom de classe tel que “.left » aura peut-être plus rapidement du sens que « .minor » ou autre terme « sémantique ».

La Sainte Sémantique

Il faut la respecter, c’est vrai. C’est ce qu’on rabâche tout au long de nos formations.

Mais au fait, c’est quoi la sémantique ?

Est-ce simplement choisir les balises HTML selon leur fonction ?
OK, un h1 est un titre de niveau 1, un blockquote est un bloc de citation. Soit. Mais que faire des éléments b, i, u, qui avaient un sens, l’ont perdu puis l’on retrouvé en HTML5 ?
Et que faire des nouveaux éléments tels que aside, figcaption, footer pour les agents utilisateurs qui ne les reconnaissent pas ?

Quid de microdata, des microformats qui enrichissent vraiment la sémantique des documents, les employez-vous constamment, parfois, jamais ? Et vous osez critiquer les classes “non-sémantiques” ? 😉

Les noms de classe CSS “sémantique”, cela n’existe pas. Que votre classe s’appelle “bloc-info » ou « left”, l’agent utilisateur n’en aura cure, il récupère le sens ailleurs dans le code (dans le choix des balises, avec les microformats, etc.)

Par contre, cette information est cruciale pour vos collègues qui eux ont besoin d’information significative dans ces noms de classes CSS choisis. Et il il y a fort à parier que “left » soit plus parlant que « aside-info”. Certes, pas toujours.

EDIT du 25/07/2012…

Suite à une très intéressante discussion par e-mail avec Karl Dubost, j’avoue que je me suis trompé au sujet de la “sémantique des classes”. Pour tout dire, les class HTML ont aussi historiquement une portée sémantique selon les spécifications :

The class attribute has several roles in HTML:

• As a style sheet selector (when an author wishes to assign style information to a set of elements).
• For general purpose processing by user agents.

En clair, au sein d’un contexte donné, il est tout à fait pertinent et judicieux de se servir de l’attribut class pour véhiculer de l’information, par exemple class=”author”, afin de pouvoir extraire tous les auteurs d’une page.

Pensez réutilisable !

Nicole Sullivan après avoir analysé et repris en intégralité les codes HTML et CSS du site Facebook a réussi à réduire de plus de 30% le volume de code produit (et les temps de chargement).

Sa technique ? Éradiquer toutes les duplications et répétitions de code inutiles et rendre chaque sélecteur indépendant de son contexte. C’est là où des classes telles que “left » ou « mod » ou « clearfix » se révèlent infiniment plus réutilisables que « aside-info”.

Comment rendre réutilisable au maximum sa feuille de style ?

1. Chaque élément doit avoir un “nom” (une classe CSS) qui pourrait être utilisé dans n’importe quel contexte
2. Les id doivent être évités (sauf exceptions) car trop spécifiques dans le calcul du poids du sélecteur
3. Les sélecteurs en cascade doivent être évités de manière générale (.header .info)
4. Le bulldozer !important doit être éradiqué

Vous l’aurez compris, certain de ces concepts vont parfois (souvent) à l’encontre des anciens préceptes établis.

Je ne suis pas très porté sur les extrémismes : les préceptes ancestraux ont du bon, il ne faut surtout pas les balayer d’un revers de main sous prétexte qu’ils peuvent être remis en question dans le cadre de projets en production.

Si j’avais un conseil final à donner, ce serait : sachez prendre du recul, forgez-vous votre opinion et surtout, discutez-en avec vos collègues de travail afin d’établir une convention interne vraiment cohérente et personnelle.

PS : je finis avec un peu de pub pour KNACSS, qui est complètement étudié pour des projets modulables et réutilisables 😉

Ah oui, n’oubliez pas que le livre CSS Maintenables de Kaelig Deloumeau-Prigent est une excellente ressource pour vos CSS en production.