En février dernier, les différents fabricants de navigateurs (Mozilla, Opera et Microsoft) ont exprimé leur souhait d’interpréter certaines propriétés CSS3 avec le préfixe -webkit-. Le lendemain, Daniel Glazman (co-président du groupe de travail CSS du W3C) lançait un appel à tous les développeurs web pour éviter que cette situation ne se produise. Le message a été plutôt bien relayé par la communauté du développement web et du design web. Malheureusement hier, le magazine .NET rapportait qu’Opera s’apprêtait de manière imminente à implémenter et interpréter certaines propriétés avec le préfixe -webkit- :
Opera, aux côtés de Microsoft et Mozilla, ont annoncé lors d’une réunion du CSS Working Group qu’ils supporteraient certaines propriétés avec le préfixe WebKit. C’est parce que trop d’auteurs de sites mobile utilisent uniquement les propriétés avec un préfixe -webkit-, et même pas la version standard, sans préfixe, lorsqu’elle est disponible. Cela mène à une expérience utilisateur réduite sur Opera, Firefox Mobile et IE Mobile, qui n’affichent pas les mêmes effets à la mode, comme des transitions, des dégradés, même s’ils supportent ces effets.
Il y a trois mois, je résumais le ridicule de la situation, auquel j’ajoute aujourd’hui cette représentation Tarantino-esque de l’état du web.
Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.
Je l’ai dit hier et je le redis aujourd’hui : c’est une honte. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs favorisent leurs propres intérêts personnels au détriment du Web Ouvert. C’est particulièrement honteux de la part d’Opera et surtout Mozilla qui se vantent sans cesse de défendre le Web Ouvert.
Qu’on soit bien clair : l’origine de tout ce débat, l’origine du problème, ce n’est pas le W3C, ce ne sont pas les navigateurs. Ce sont nous, petits intégrateurs, qui sommes la cause de ce problème. Ou plutôt, les intégrateurs peu consciencieux ou peu avertis, qui utilisent uniquement des préfixes -webkit- sans se préoccuper des autres navigateurs.
Je me considère comme un intégrateur un minimum averti. Je travaille en agence depuis 6 ans, et je fait de la veille que je partage quotidiennement sur Twitter ou sur ce blog. J’estime être relativement au courant des nouveautés du web et en particulier en intégration. Au fil des années, de ma part mon travail et également via Twitter, j’ai rencontré et discuté avec des dizaines voire une centaine d’intégrateurs. Des intégrateurs freelance, des intégrateurs en agence, des intégrateurs chez l’annonceur pour de plus ou moins grands comptes. En dehors de la sphère Twitter et de la petite famille francophone de développeurs web, j’ai très souvent constaté qu’une bonne partie d’intégrateurs sont souvent mal renseignés sur leur métier. Dans certains cas, c’est parce qu’ils considèrent l’intégration comme un simple métier, et qu’ils n’éprouvent pas l’intérêt de faire une veille quotidienne. Dans d’autres cas, c’est par manque de temps et par épuisement. Par exemple, j’ai rencontré un jour une intégratrice qui travaillait dans une agence où elle devait intégrer chaque jour un site complet (de 10 à 20 pages). Difficile de trouver le temps de faire de la veille dans de telles agences.
L’origine du problème, c’est donc le manque de formation et de connaissances détaillées dans le web pour une grosse partie des intégrateurs, développeurs web ou webdesigners. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs ne vont pas résoudre l’origine du problème. Ils vont l’aggraver. Ces intégrateurs vont continuer à utiliser des propriétés avec le préfixe -webkit- uniquement, en se satisfaisant que ça fonctionne désormais partout. Mais ils ne se remettront pas en question, et ils n’aideront pas à rendre le web meilleur.
Alors quelle est la solution ?
Beaucoup d’intégrateurs souhaiteraient tout simplement l’abandon des préfixes navigateurs. Mais ces préfixes sont utiles et nécessaires. Ils permettent aux navigateurs d’implémenter des fonctionnalités en cours de définition par le W3C, et aux développeurs de les tester. Mais à tout moment, ces propriétés sont susceptibles de changer, pour être améliorées voire supprimer. C’est ce qui est arrivé avec les définitions des dégradés en background. La première syntaxe proposée par le W3C a été revue et adoptée par les autres navigateurs suite à la proposition d’une meilleure syntaxe par Mozilla.
Alors quelle est la solution ?
Je n’ai pas la prétention d’avoir une solution miracle. Mais par expérience, je sais une chose : si à un moment donné, un navigateur affiche un message alarmant à l’internaute sur un site donné, alors toute la hiérarchie d’une boîte va se réveiller pour que ce soit corrigé au plus vite. J’ai souvent rencontré le cas sur IE6. Sur IE6, quand vous êtes sur une page en HTTPS et que vous appelez une ressource en HTTP, le navigateur affichera une alerte à l’internaute lui demandant s’il souhaite afficher ou pas les contenus non sécurisés. A chaque fois que j’ai aidé des clients à résoudre ce problème sur leurs sites, croyez moi, toute la hiérarchie était sur le coup : des remontées du service téléphonique client au département marketing jusqu’à la direction générale. L’origine du problème vient également d’une mauvaise pratique de la part du développeur web, qui n’a pas pris le soin d’appeler des contenus sécurisés partout. Mais en corrigeant ce problème, le développeur web apprends quelque chose. Et s’il tient à sa survie, il y a de grandes chances qu’il retienne la leçon.
On pourrait alors imaginer un message d’alerte similaire, laissant entendre que le site a été mal conçu, et lui proposant d’améliorer le rendu du site. Si l’internaute accepte, le navigateur pourra interpréter les préfixes -webkit-. Sinon, la page s’affichera normalement.
Avec une telle solution, tout le monde est gagnant. L’internaute peut afficher une version optimale du site. Le navigateur peut démontrer ses capacités. Et le développeur web et les concepteurs du sites seront invités à revoir leurs pratiques.
J’espère vraiment que la décision d’Opera et de Mozilla n’est pas figée, et qu’ils essaieront de travailler avec des développeurs web pour trouver la meilleure solution, plutôt que d’imposer au monde entier leurs mauvaises décisions.
Cqoicebordel, le
Cette solution, même si elle pourrait fonctionner, est totalement inapplicable.
Un des problèmes rencontré par Opera notamment est par exemple un gradient défini en -webkit- sans couleur de fallback, avec un texte en blanc par dessus. Et ça s’affiche donc en blanc sur blanc dans Opera. C’est quelque chose qui est extrêmement compliqué à détecter programmaticalement. Et on ne peut pas dire que c’est uniquement parce qu’il y a une balise -webkit- sans les autres qu’ils s’agit d’une erreur. Il s’agissait peut-être d’une correction d’un bug graphique sous webkit.
Bref, il ne s’agit pas d’une solution satisfaisante.
(lire les commentaire de Bruce Lawson ici : http://www.iandevlin.com/blog/2012/04/css/on-vendor-prefixes-and-wods/comment-page-1 )
Daniel Glazman, le
Pas si simple que ça à mettre en oeuvre, malheureusement.
Bartdude, le
Je pense que la solution proposée est un peu extrême, à la limite de la dictature du puriste. Je comprends le débat et suis entièrement d’accord avec toi sur le fond, mais il n’y a pas si longtemps tu parlais de monsieur tout-le-monde… L’alerte « https » dont tu parles n’est pas là que pour pointer du doigt une best-practice, il y a vraiment des implications de sécurité. Mais dans le cas présent, pourquoi alerter monsieur tout-le-monde sur un problème qui ne le concerne finalement pas ? Pour faire bouger les intégrateurs peu consciencieux ? Dans ce cas, on pourrait imaginer beaucoup d’alertes du même genre… où commencer ? où s’arrêter ?
Je n’ai pas non plus de solution miracle, mais si le but est de « forcer la main » aux intégrateurs, le non-support des préfixes me paraît à la limite bien plus efficace qu’un message d’alerte… je ne sais même pas pourquoi cela fait débat, je trouve ca affligeant tout comme toi !
Rodleg, le
Tout d’abords merci et bravo pour cet article .
Je suis d’accord avec toi c’est une honte en ce qui concerne les navigateurs, il n’y a pas d’autres mots, on oublie l’open web et on ne pense qu’à son petit bizness. Dans quelques années les intés se rendront compte qu’Opera est une bien plus grosse merde que ne l’était IE à l’époque.
Pour les intégrateurs qui s’extasient devant Css3 (9 fois sur 10 pour foutre bêtement des shadows et des border-radius mal grérés et tout dégueulasses!) et qui ne joue pas le jeu d’un web ouvert, ils se tirent purement et simplement une balle dans le pied.
J’espère vraiment que tout les acteurs du web vont se réveiller et prendre conscience de que tout ceci relève de la connerie la plus profonde.
Ced, le
D’accord sur l’ensemble de l’article (je viens de le voir après y avoir été de mon grain de sel http://cedrey.tumblr.com/post/21845971880/css3-le-bazar-commence).
Mais comme je le disais de mon coté, je trouve que la part de responsabilité du W3C n’est pas négligeable non plus. Le web évolue vite, on se débarrasse de flash pour des solutions ouverte et normées, et pourtant, depuis combien d’années le CSS3 est à l’état de draft? En tous les cas les modules les plus intéressants tels que les gradients ?
Certes, il est très intéressant de voir le travail effectué sur cette dernière propriété, mais n’est-elle pas prête à être utilisée pleinement maintenant? Nous avons les outils pour générer le code d’un dégradé, mais si nous ne pouvions avoir à copier qu’une ligne au lieu de 10.
Les navigateurs, à la fréquence des mises à jour actuelle, pourraient répondre très rapidement à une « mise en prod » de certains modules CSS3, n’y a t-il pas urgence pour pallier à ce manque de rigueur des intégrateurs, qui, je le reconnais également, ont une énorme part de responsabilité ? (back in IE6-blink-marquee-activeX les gars, qu’on rigole un bon coup…)
PS : de plus, quelle hypocrisie des éditeurs de voir par exemple les box-shadow ou text-shadow reconnus sans préfixe et nous sortir l’excuse du préfixe webkit pour le reste…
maxim, le
moi je n’ai toujours pas compris l’intérêt des préfix mais bon…. pourquoi ne pas mettre par exemple border-radius et si le browser le supporte, tant mieux ?
JohnKrovitch, le
Je suis assez d’accord avec l’ensemble de l’article, mais pas trop pour la solution proposée, qui comme le dit Bartdude, informerais l’utilisateur d’une alerte dont il se fiche totalement, non ?
Utiliser des outils comme Compass pour gérer ces préfixes me parait une solution acceptable : on n’a plus qu’une ligne par propriété, et Compass rajoute lui-même les préfixes navigateurs. Du coup dans le code, le développeur n’a plus qu’une ligne par propriété, les préfixes sont gérer, reste à la charge des développeurs de Compass de supprimer ces préfixes lorsque les propriétés css sont disponibles.
Gring, le
La solution que tu proposes ne serait viable que si Opera et Firefox avaient une part de marché suffisamment lourde sur mobile pour tenter ce coup de poker.
En pratique, si la page de madame Michu s’affiche mal, elle désinstallera sèchement le navigateur pour passer à la concurrence. Le grand public se fiche pas mal du web ouvert et du logiciel libre, il suffit de voir le succès d’Apple malgré certaines de leurs pratiques.
Ce que je trouverais acceptable, c’est que ces navigateurs passent en « mode de compatibilité webkit » (éventuellement signalé par une petite îcone) lorsque des propriétés préfixées webkit sont détectées sans leur équivalent global, à condition que le support soit identique.
Draeli, le
Pourtant fervent fan de Opéra depuis des années, je dois avouer avoir été surpris par cette décision qui à mon sens est une ignominie et une hérésie total. Ceci dit, ça reprend peut-être ce qui a était aussi un peu le jeu de Firefox (je ne sais pas si c’est encore dans la politique actuel) qui a émulé certains bogues de IE afin que les intégrateurs puissent faire leur site sans avoir à se rendre fou. Donc de ce point de vu on pourrait penser que ca part d’une bonne action.
Maintenant en tant qu’intégrateur, je demande pas à ce qu’on me fasse de l’assistanat, l’intégration est un métier et la veille technologique FAIT parti du métier et prendre du temps pendant ses horaires de boulot pour faire un suivi de ce qui ce fait et des « bonnes » pratiques de l’état de l’art est normal (même si certaines Entreprises peines à le comprendre).
A la réflexion, j’en arrive à plusieurs points :
1 : il y a beaucoup trop de pseudo-« intégrateurs » ou qui se revendiquent comme tel alors qu’en grattant un peu … c’est un désastre. Être autodidacte c’est bien mais faire du travail d’amateur qui tout au mieux dans certains cas sera du travail d’amateur « averti » tire vers le bas vers ce métier qui peine malgré tous (en tous cas pour le cas de la France) à se faire reconnaître comme tel. Or ce n’est pas avec ce genre de politique que Opéra aidera la profession à se faire une place respectueuse dans les métiers d’Internet, car c’est un vrai métier et un métier très compliqué.
2 : le W3C n’avance pas assez vite, certes, il serait difficile de le nier mais dans ce cas la, pourquoi ne pas donner ce qu’il manque à celui-ci pour avancer plus vite ? En se regroupant, les différents acteurs de la navigation Web ont largement les moyens financier, méthodologique et les compétences pour faire avancer celui-ci donc la c’est hypocrite de la part de ces derniers de faire leur implémentation de leur côté et venir faire une critique.
3 : vouloir avancer vite c’est bien, mais vouloir avancer à tous prix, cela donne des situations qui à l’heure actuel complique beaucoup la vie des intégrateurs (qui n’ont pas spécialement besoin de cela) et des projets en général. Sur ce point, j’ai souvent l’impression que les intégrateurs sont la pour « essuyer les plâtres ».
Je pourrai encore continuer sur d’autres points mais déjà à ce niveau, la situation n’est clairement pas en faveur de la politique de Opéra.
—-
Pour en revenir à ta solution de la boîte « alert », je pense que c’est une vrai-fausse bonne idée car la problématique de la présentation ne touche pas l’utilisateur dans sa sécurité au travers de son usage du site.
Le mieux pour moi est encore la solution actuel de multiple déclaration est prévoir de la dégradation gracieuse.
C’est déjà ce qui ce fait pour les mails depuis des années et ca convient très bien à tous le monde, seulement il semblerait que pour la création de page Internet, cette philosophie est encore du mal à s’ancrer et sur ce point je pense que les intégrateurs ont un vrai travail de communication à faire pour faire comprendre aux décideurs de projet que « Oui c’est bien le ‘pixel perfect’ mais qu’une dégradation gracieuse bien pensée permettra tout aussi bien l’utilisation du site avec un coût temps réduit et un impact utilisateur tendant vers un facteur nulle ! ».
Au final, ma conclusion en quelques mots est :
– pour les intégrateurs être plus impliqués en terme de communication projet
– pour les acteurs de la navigation Internet, se bouger pour faire avancer le W3C et être plus à l’écoute des intégrateurs
ps : ceci est ma vision en quelque mot, mais pour affiner mon point de vu, il faudrait que j’écrive beaucoup plus ^^
Yvain Liechti, le
Bonjour !
Même si ça à l’air d’un gros troll, je pense que nous n’aurions pas dû utiliser les préfixes en production.
Il est certain que ces fonctions sont vraiment attrayantes mais non-normalisé. C’est un peu comme faire roulé sur la voie public un prototype non homologué (c’est risqué).
Si les préfixes ont étés mis en place, c’est d’abord pour pouvoir tester.
Ce qui me fait peur c’est que pour une inter-et-retro-compatibilité on va avoir des pages entière de préfixes à maintenir. Car chaque futur propriété aura un préfixe par navigateur avant que la norme soit officiel.
C’est surement radical comme idée mais c’est la seule qui serait maintenable à long terme sans aller à l’encontre des standards de normalisation.
thierry, le
« C’est ce qui est arrivé avec les définitions des dégradés en background. La première syntaxe proposée par le W3C a été revue et adoptée par les autres navigateurs suite à la proposition d’une meilleure syntaxe par Mozilla. »
Bonjour,
C’est un peu hors sujet, mais j’ai besoin de la savoir et je m’y perds, avec tous les articles sur le sujet datant d’un an, deux ans ou plus dont je ne sais pas s’ils mentionnent cette dernière syntaxe pour les dégradés.
Quelqu’un pourrait-il me dire quelle est cette dernière syntaxe ou me fournir un lien vers un article à jour ?