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 un résumé 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 1) 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!) et 2) 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? Moi si on en arrive à ça je pars élever des chèvres dans le Larzac ou alors je m’en fous et je fais du Flash.
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. Vous pouvez même le copier-coller et mettre votre nom à la place du mien, rien à fiche, faites juste tourner. :)
-
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.
À vous maintenant: Quelles méthodes utilisez-vous? Que pouvez-vous améliorer dans vos pratiques? Comment pouvez-vous faire passer le message?
Commentaires
Quand on écrit une propriété CSS3, les préfixes sont une plaie : compliqué à maintenir, ordre à respecter, code qui devient illisible…
Pour ne pas avoir à me préoccuper de toute cette interopérabilité et produire un code élégant, j'utilise Compass, le fidèle compagnon du préprocesseur CSS nommé Sass.
Compass compile les propriétés CSS3 en tenant compte des différences d'implémentation d'un navigateur à l'autre.
Pour ceux qui utilisent Less (ou tout autre préprocesseur CSS), je vous encourage à créer des mixins équivalents ou à vous baser sur des bibliothèques de mixins CSS3 existantes.
http://compass-style.org/
Très intéressant comme article, je l'ai gazouillé pour le coup ;)
Je vais faire un peu l'avocat du diable mais Apple et Google n'ont fait que suivre les recommandations du W3C en shippant leurs propriétés expérimentales préfixées. On ne peut pas leur en vouloir d'avoir du succès, c'était plutôt amha une erreur de la part du W3C d'admettre que ces propriétés préfixées soient aussi facilement utilisables en production par monsieur tout le monde…
Merci pour ce très bon article,je fais tourner :)
Je me pose des questions sur GWT, le framework Web Java de Google que j'utilise sur mon projet actuel.
Car en fait il fait à la fois du user-agent sniffing et essaye d'optimiser le code spécifiquement pour le navigateur client.
Je me demande notamment si sur le moyen terme ça peut tenir, avec les multiples évolutions possibles.
Avez-vous un avis dessus?
ReTweet fait
génial twitter les infos importantes me parviennent 2 fois :)
bref au boulot :)
La méthode la plus simple quand on utilise une base de snippets est de charger toutes les versions de propriétés pour chacun.
Exemple : border-radius > -webkit-border-radius:, -moz-border-radius:, border-radius: ...
Et une mise à jour des snippets avec les nouveautés permet de suivre le mouvement !
M'en fou des prefixes, j'utilise Sass avec Compass :p
@bdc: Il s’agit pas de mettre la faute sur Apple et Google de toute façon. Ils ont leur part de responsabilité dans leur communication (faites un site compatible iPhone|Android, allez hop utilisez telle propriété -webkit-machin), mais techniquement ils ont plutôt respecté les règles oui, plus que Microsoft avec les ajouts non-standard d’IE 5-6 à l’époque. Ça n’élimine pas le danger et le besoin pour tous de faire des efforts pour ne pas retomber dans les mêmes pièges.
@Francois_Petitit: pour GWT, il utilise apparemment des techniques dangereuses. Si le framework est mis à jour très régulièrement et que toi aussi tu mets à jour ton application régulièrement, ça minimise le danger. Mais on fait tous des sites lancés en production et sur lesquels on n’intervient plus ou juste occasionnellement, donc le risque est bien là. Après je ne connais pas dans le détail ce que fait GWT en la matière.
Un autre moyen pour se débarasser des préfixes: Prefix-free, un petit script js. http://leaverou.github.com/prefixfree
Je relaie l'info avec mon avis sur mon site perso : http://www.nicolas-hoffmann.net/source/1451-A...
@fvsch : très bon article qui résume bien la situation, je me suis permis de le retwitter et de le bloguer
@Jvtanguy : J'allais le suggérer !
Je n'aurais pas pensé qu'il y ait des dev assez fainéants pour ne pas ajouter les préfixes autre que -webkit-* surtout quand on voit le peu de travail que ça demande.
Bonjour et merci pour cet article !
Sans le remettre en cause, j'ai voulu exprimer mon humble avis sur mon site : http://jebulle.net/nous-sommes-les-garants-du...
Le leadership de Webkit est très inégal selon les région. En France il est incontestable (~90% du marché), mais par exemple au Royaume-Uni il y a encore un tiers de RIM. Mondialement, le "leader" est opéra, grâce à l'Asie, l'Afrique, etc. Donc les dev qui font du Webkit seul sont à côté de la plaque.
Et plus généralement on peut rapprocher ce danger avec l'échec de l'implémentation à préfixe. Loin de garder ces fonctionnalités expérimentales on les utilise massivement en prod, avec même des frameworks pour nous aider à utiliser des fonctionnalité que l'on est pas censé utilser... Oo.
@fvsch GWT est un framework destiné à réaliser des interfaces riches pour des applications web. Ce genre d'application n'est en effet pas vendable sans un contrat de maintenance onéreux et complet. Du coup, cela me choque moins.
«par exemple au Royaume-Uni il y a encore un tiers de RIM»
Les téléphones RIM récents (BlackBerry OS 6 et 7) utilisent WebKit. Mais il doit y avoir pas mal de BlackBerry OS 5 encore en circulation (certains téléphones ont été écoulés jusqu’en 2011 par les opérateurs).
Il faut aussi faire la différence entre téléphones mobiles et usages du Web mobile. Entre un ado avec un BlackBerry, accro à BBM mais ne surfant jamais sur le Web, et un utilisateur d’iPhone qui utilise le Web en 3G à tout va, ça ne donne pas la même choses en termes de parts de marché *web*. De même, Opera est très largement installé, mais les usages suivent-ils?
Une partie de la focalisation sur WebKit pour les mobiles vient du fait que les stats des sites web ont commencé à montrer des visiteurs sur Safari iPhone, puis des visiteurs sur Android Browser, là où d’autres plateformes mobiles (OS et navigateur) généraient et génèrent toujours très peu de trafic.
Au temps pour moi et le moteur de rendu du blackberry browser (la honte!), mais l'ado est pas vraiment la clientèle blackberry, c'est plutôt les systèmes téléphoniques d'entreprise (jusqu'à quand?) ! Les stats que je cite sont celles des visites sur site, celles de stat counter en l'occurence, qui ne sont certes pas paroles d'évangile mais quand même intéressantes.
Sinon que se soit un monopole ou une très forte supériorité, cela reste en effet inquiétant/à surveiller.
Sinon pour ma méthodologie j'applique quelque chose de simple qui évite l'addiction aux fonctionnalités expérimentales:
Je base mes designs sur ce que je souhaite faire, en dehors de toute considération technique (j'évite quand même quelques choix qui me rendront la vie impossible), puis j'adapte au besoin lors de la mise en œuvre technique. Cela évite non-seulement le "je met des bord-rond partout parce que maintenant c'est facile à faire", mais aussi là surenchère de fonctionnalités css nouvelles, sans apport réel pour l'utilisateur.
Bel article et tellement vrai. Il y a quelques jours j'essayais d'expliquer au service Digital de mon entreprise, que la programmation en html5/css3 devenait très chronophage. Même entre safari ipad (1) et iphone (4S) il y avait des différences et qu'il fallait tester les deux.
Je leur expliquais qu'on arrivait tout doucement à la même situation que IE6 il y a quelques années. J'espère qu'il y aura une vrai prise de conscience, car revivre l'expérience IE6 (qui pour moi c'est terminé au 1er janvier 2012) serait franchement décevant (et je rejoindrais l'auteur de l'article du Larzac, qui est au final un très beau causse pour garder de brebis).
Merci Florent pour cet article. Certaines choses que tu as écrites sont pour moi évidentes avant même que tu l'aies fait (ex : utilisation des préfixe seulement). :)
Les objectifs de chacun ne sont pas forcement les mêmes.
Il est vrai que dans pas mal d'agence, on vend aussi une compatibilité avec d'ancien navigateurs. Ce service à un prix aussi. Je vois de plus en plus de jeunes qui se lance faire des presta "pas chère", parce que leurs travaux sont aussi un peu plus facile sans cette compatibilité.
Cela dépend des travaux, mais en général, j'essaie de limiter l'usage de ces préfix quand ils ne sont pas nécessaire. Par exemple c'est la mode de tout mettre en arrondis maintenant, alors que parfois un angle droit rend tout aussi bien, et reste compatible ! ( j'avoue que l'exemple n'est pas des plus pertinents ... )
N'étant pas un chevronné, je me dis que si ça marche avec un minimum d'effort tant mieux sinon tant pis.
Je ne supporte plus ie6 depuis un petit moment, ( je vérifie tout de même ce que cela donne, et si il manque juste un petit quelque chose, je fais sinon tant pis. )
Je pense que l'on faire de bonne chose avec ie8 (avec quelques léger point de colle à ie7 si ça mange pas de pain), mon avis s'accentue au fur et a mesure que je lis les aventures de Raphael Goetter ( ie7nomore car mine de rien on fait de bonnes choses en CSS2).
Je fais une sorte de pari, puisque aujourd'hui ceux qui ont ie7 peuvent avoir facilement le 8 (et ceux ayant passé xp peuvent avoir 9 et 10 ... ) Sans compter que maintenant rare seront les applis uniquement compatible ie.
Mais je rejoint l'avis ici, je vois de plus en plus de sites compatible avec les dernières versions de webkit, sans avoir de solution de replis ( même minime ... )
J'ai l'impression de revivre mon collège, avec des « site compatible sur machin-chouette uniquement en résolution AAA x BBB »
Si jamais, une version francophone a été mise sur Openweb http://openweb.eu.org/ (pour les anglophobes ... les anglo-qui-ont-du-mal) ;)
Merci pour cette excellente paraphrase !
A noter que des solutions comme SASS, LESS et autres peuvent faciliter l'utilisation et la maintenance de ces propriétés "expérimentales"...
Vraiment un super article, très intéressant.
Je fais tourner.
Utilisation de Prefixr dans Sublime Text 2.
Je tape ma déclaration sans préfixe, Ctrl+Alt+X, et Prefixr se charge de noter tout le reste sus base d'une BDD tenu à jour.
Gain de temps, tout le monde est content.