Les bonnes pratiques CSS sont plus ou moins respectées par la communauté des intégrateurs / développeurs web. Daniel Glazman, coprésident du CSS Working Group (groupe de travail sur CSS du W3C), a écrit un appel à action important: THE OPEN WEB NEEDS YOU *NOW*. Pourquoi ? On explique !

C’est quoi ce truc

En résumé, ce gentil monsieur nous dit qu’on est en train d’entrer dans une période de crise (quoi, encore une ?) pour le web ouvert. Le monde des standards va mal.

Souvenez-vous, la Grande Epoque, l’Age d’Or, ou le Saint IE6 régnait en maître sur la toile d’araignée mondiale (c’est lui la toile d’araignée ouais !). Tout le monde ou presque était content et se disait, « Internet Explorer, c’est le meilleur », ou encore, « attends je vais sur l’Internet, il est ou le e bleu là ? ». Et oui, IE6 avait le monopole, et du coup, il faisait un peu ce qu’il voulait. Et vu qu’il faisait ce qu’il voulait, les développeurs rampaient et venaient lui manger dans le e, et concevaient des sites à son image. Et les standards dans tout ça ? Ils pouvaient rentrer chez eux.

En effet, une situation de monopole n’est jamais bonne pour le bien-être de nos standards préférés… L’éditeur du navigateur en position dominante est tenté de proposer ses propres fonctionnalités non standards, parfois expérimentales ou mal finies, et de les imposer, ce que les créateurs de sites suivront à la lettre pour coller au principe d’accessibilité. Ce qui n’est pas terrible là dedans, c’est que tout ceci mène à renforcer le monopole, diminuer la concurrence et donc l’innovation sur le web. La fin de l’apogée de ce très cher IE6 en est un très bon exemple, puisqu’à cette période a suivi un gros blackout général dans le monde de l’évolution du web. Heureusement, on en n’est plus là.

Sauf que l’heure est aujourd’hui à l’arrivée d’un nouveau monopole : celui du moteur de rendu WebKit sur les plateformes mobiles (smartphones, tablettes) et au-delà (le nouveau navigateur embarqué de la PlayStation 3 utilise WebKit par exemple). Il est donc certain que WebKit détient un monopole d’attention chez les créateurs de sites web : nous avons tous commencé à nous intéresser au développement de sites mobiles avec le succès de l’iPhone et en parallèle celui d’Android. Et si vous avez suivi ce que j’ai évoqué plus haut, vous vous dites la même chose que moi : IE6 et Webkit pourraient au final avoir bien des choses en commun en ce qui concerne l’évolution du web, et nous, on veut pas de ça !

On doit mettre Webkit en kit ?

Je ne suis pas en train de dire qu’il faut opérer un boycott massif de Webkit, non, Webkit c’est bien, c’est beau, c’est véloce. Mais on peut tendre vers une utilisation plus « normée » de celui-ci. Il y a deux erreurs qui sont commises régulièrement par les développeurs web :

• Utilisation du browser sniffing (détection du navigateur via la chaine User-Agent ou d’autres informations) pour réserver une fonctionnalité aux navigateurs WebKit ou à l’iPhone, voire carrément un blocage de l’accès au site mobile pour les navigateurs non WebKit.
• Utilisation de propriétés CSS expérimentales avec préfixe -webkit-*, sans doubler ces propriétés par les syntaxes équivalentes pour les autres navigateurs et sans se soucier de la compatibilité.

Et oui, le truc c’est que tout le monde veut arriver à faire de la nouveauté avant tout le monde, même si on dit que c’est expérimental, que ce n’est pas stable.

Si Mozilla, Opera et Microsoft se prêtent à ce jeu, on risque une spirale infernale bien connue : des fonctionnalités non standards (jamais proposées comme standards à l’instar de -webkit-text-size-adjust, ou expérimentales et amenées à changer comme -webkit-gradient() proposé en 2008 et remplacée par une nouvelle syntaxe avec déjà deux itérations…) commencent à être reconnues par plusieurs navigateurs, deviennent des standards de fait alors que ce ne sont que de vagues fonctionnalités expérimentales vouées à évoluer, voire à mourir. Mais trop tard, tout le monde les utilise à outrance, éventuellement en râlant un peu parce que c’est pas terrible ou limité, mais tant pis.

Le problème, c’est que si en quelques mois, une nouvelle proposition expérimentale dans WebKit devient un standard de fait par l’utilisation massive qu’en font les créateurs de sites, on risque d’utiliser dans cinq, dix et vingt ans des fonctionnalités mal finies et être condamné à râler en boucle. Gros problème de qualité en perspective ! Vous vous imaginez utiliser aujourd’hui, dans tous les navigateurs, les filtres DirectX d’IE5-6 à la place des effets CSS3 modernes ? Si on en arrive à ça, je fais mes sites en PowerPoint, en voilà un beau standard.

Les bonnes pratiques à avoir !

Pour éviter que les éditeurs de navigateurs ne cassent les standards du Web, c’est à nous, gentils designers / développeurs / intégrateurs de faire attention à la monoculture WebKit. Voilà les bonnes pratiques CSS à utiliser :

• Créer une base fonctionnelle solide avec des fonctionnalités HTML, CSS et JavaScript éprouvées par le temps.
• Dans le même ordre d’idée, il faut exploiter au maximum les fonctionnalités déjà stables: HTML 4 et CSS 2.1 bien sûr, mais aussi les parties de HTML5 et CSS3 qui sont stables et implémentées sans préfixe dans au moins une partie des navigateurs.
• Pour savoir si une fonctionnalité est stable ou non, on peut aller faire un tour du côté de When Can I Use… (caniuse.com). Si une fonctionnalité n’est pas implémentée par la moitié des navigateurs, on devrait l’éviter. Si elle est largement implémentée mais que tous les navigateurs requièrent l’utilisation d’un préfixe, la fonctionnalité n’est sans doute pas stable et pourrait changer radicalement ou même être abandonnée… Enfin, si les navigateurs commencent à proposer la fonctionnalité sans préfixe, c’est qu’elle est probablement stabilisée.
• Lorsqu’on utilise une fonctionnalité expérimentale, il faut utiliser au maximum les préfixes des différents moteurs de rendu, et terminer par une version sans préfixe. Au moins la compatibilité est assurée pour tout le monde, et le monopole est atténué.

Voilà donc tout ce que le monsieur du début voudrait que l’on puisse faire pour éviter de revivre un « IE6 time like », et il a bien raison. Mais on sait tous que c’est facile de parler, et tout de suite plus compliqué quand il s’agit de se mettre les mains dans le cambouis… Alors à vos clefs à molette !

Popularité de l'article : 2%