(Article initial : fvsch )
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*. C’est une lecture fortement recommandée pour tous les développeurs et designers web. Voici une paraphrase en français du problème exposé, et quelques préconisations que vous trouverez peut-être utiles.
Ne pas refaire l’erreur d’IE6
Si vous avez un peu suivi l’histoire du Web, vous savez que les situations de monopole ne sont pas bénéfiques pour les standards : l’éditeur de navigateur qui a le monopole ou quasi-monopole peut être tenté de proposer des fonctionnalités sans les proposer comme standards, les créateurs de sites web utilisent du code non-standard qui ne fonctionne que sur le navigateur qui a le monopole, et les éditeurs minoritaires sont tentés d’imiter les comportements non standard du navigateur minoritaire. Un jeu très dangereux pour l’efficacité des standards, qui mène à renforcer les monopoles, diminuer la concurrence et donc l’innovation sur le Web. La stagnation du Web quand Microsoft a arrêté le développement d’Internet Explorer après IE6 et pendant plusieurs années en est une preuve suffisante.
Aujourd’hui, nous sommes devant 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). Dans les faits, Opera Mini et Opera Mobile restent des concurrents non négligeables sur mobile, mais il est 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 l’arrivée de l’iPhone ou dans les années suivantes avec le succès de l’iPhone et en parallèle celui d’Android.
Pour beaucoup, le Web mobile c’est WebKit et puis c’est tout
C’est une vision à court terme particulièrement dangereuse. Certes, personne ne peut jurer que Windows Phone ne fera pas un flop, que Firefox et Opera arriveront à s’implanter fermement comme navigateurs alternatifs sur Android et d’autres plateformes, ou que de nouvelles plateformes pour mobiles ou tablettes viendront changer un peu la donne. Mais en 2002 beaucoup pensaient que la partie était finie, qu’Internet Explorer avait gagné la guerre et qu’on arrivait à une période de stabilité. En réalité on a eu droit à une période de stagnation (arrêt du développement d’Internet Explorer, entrainant un retard que Microsoft rattrappe à peine) et une redistribution des cartes quelques années plus tard notamment grâce à Firefox. De nombreuses entreprises se mordent encore les doigts d’avoir fait développer des logiciels de gestion dont les interfaces sont compatibles uniquement avec IE6.
En pratique, le problème c’est quoi ?
Il y a deux erreurs qui sont commises régulièrement par les développeurs web, et pas uniquement les moins informés :
- 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é
Ces problèmes sont déjà courants sur des sites destinés à tous les supports (sites développés avec les techniques désormais nommées Responsive Design). Ils sont extrêmement courants sur les sites dédiés aux périphériques mobiles.
Aujourd’hui, les éditeurs de navigateurs minoritaires veulent :
- se faire passer pour des navigateurs WebKit ou pour Safari Mobile en envoyant une chaine User-Agent frelatée (une technique vieille comme le monde, les premières versions d’Internet Explorer le faisaient déjà pour se faire passer pour Netscape !)
- lire certaines propriétés CSS
-webkit-*. Le but est d’être compatible avec les sites mobiles qui, pour beaucoup, les mettent à la porte parce que vous comprenez ce soir c’est pas possible c’est une soirée privée WebKit
Si Mozilla, Opera et Microsoft se prêtent à ce jeu, on risque une spirale infernale bien connue : des fonctionnalités non-standard (jamais proposées comme standards à l’instar de -webkit-text-size-adjust, ou expérimentales et amenées à changer comme feu -webkit-gradient() proposé en 2008 et remplacé par une nouvelle syntaxe avec déjà deux itérations…) commencent à être reconnues par plusieurs navigateurs, deviennent des standards de fait sans que la communauté des éditeurs de navigateurs et des utilisateurs (nous !) ait l’occasion de soulever des problèmes et de proposer des solutions. Quand on veut les améliorer c’est déjà trop tard, la solution plus ou moins bancale est en place et la très grande majorité des développeurs web l’utilise sans sourciller (éventuellement en pestant parce que c’est pas terrible ou limité, mais tant pis).
Alors oui, arriver à un bon standard ça prend du temps, malheureusement ça prend parfois quelques années, et il y a sans doute des choses qui peuvent être améliorées pour arriver à des résultats un peu plus rapides. Mais si en quelques mois une nouvelle proposition expérimentale dans WebKit devient un standard de fait (plutôt qu’un vrai standard communautaire), on risque d’utiliser dans cinq, dix et vingt ans des fonctionnalités mal finies et être condamnés à s’en contenter. 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 ?
Bon, qu’est-ce qu’on peut faire ?
Pour éviter que les éditeurs de navigateurs ne cassent les standards du Web, c’est à nous de faire attention à éviter la monoculture WebKit (et à l’avenir tout problème similaire). Il y a deux choses à faire :
- Faire passer le message ! N’hésitez pas à faire tourner cet article.
- Dans votre propre travail, pensez à la compatibilité avec tous les navigateurs (au moins les versions récentes, pour le support des anciennes versions c’est un autre débat). Je donne quelques conseils ci-dessous, mais vous aurez peut-être plus efficace ou pertinent à proposer en commentaire, alors partagez vos méthodologies et vos idées.
Un peu de méthode
Commencez par créer une base fonctionnelle solide avec des fonctionnalités HTML, CSS et JavaScript éprouvées par le temps. Faites simple.
Dans le même ordre d’idée, exploitez à fond 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, le site When Can I Use…(caniuse.com) est une mine d’informations. Si une fonctionnalité n’est pas implémentée par la moitié des navigateurs, évitez-la. Si elle est largement implémentée mais que tous les navigateurs requièrent l’utilisation d’un préfixe, gardez à l’esprit que 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, elle est probablement stabilisée.
Lorsque vous avez décidé d’utiliser une fonctionnalité expérimentale, utilisez au maximum les préfixes des différents moteurs de rendu, et terminez par une version sans préfixe. Ce n’est pas une solution miracle, en partie parce que c’est vraiment pénible et en partie parce qu’il est toujours possible que la syntaxe de la propriété CSS évolue (on a bien dit que c’était expérimental hein), mais tant pis, il faut se retrousser les manches et faire sa part du boulot.
Si vous pouvez l’éviter, ne faites pas reposer l’accès aux contenus ou aux fonctionnalités de base sur le support par le navigateur de certaines fonctionnalités expérimentales. Si votre mise en page est nickel dans IE10 avec CSS Grid Layout, mais complètement illisible dans tous les autres navigateurs, vous avez un problème. De même si la mise en page de votre application web mobile repose sur l’implémentation de CSS Flex Box dans WebKit, sachez que Flex Box a été réécrit depuis cette première implémentation, que la nouvelle syntaxe est plutôt différente, et qu’il est possible que votre interface web mobile soit cassée dans d’autres navigateurs… ou même dans de futures versions de WebKit ! Par définition, une fonctionnalité expérimentale peut vous exploser à la figure, et les utiliser sur des sites dont vous n’assurez pas la maintenance au quotidien est sans doute une erreur.
Sources :
Web Ouvert Css Webkit
Vendor Prefixes About To Go South/
Tous les Navigateurs Veulent Implementer le Préfixe Webkit/
Le Web Ouvert a Besoin de Vous/