« Est-ce que la grosse dame chante pour les préfixes navigateurs ? »

Kevinjohn Gallagher a écrit un chouette article détaillant le débat autour des préfixes -webkit- (rappel) et d’Opera, intitulé « Est-ce que la grosse dame chante pour les préfixes navigateurs ?« . Il a de bonnes propositions pour améliorer la situation :

La première action à prendre est de mettre la pression sur Apple/Google/WebKit pour implémenter les bons standards des propriétés en retirant le support de « -webkit- » lorsque la version non-préfixée est standardisée, et ne pas contourner le processus convenu. Ne vous trompez pas, en favorisant l’utilisation continue de « -webkit- » en dépis de la version non préfixée comme décris dans les spécifications CSS2.1 et CSS3, ce sont ces organisations qui ont donné aux développeurs la permission de ne pas écrire leur code d’une manière standard.

Deuxièmement, nous devons créer un endroit centralisé avec les bonnes informations, avec le bon niveau de détails. Vous et moi savons ce que nous faisons, mais franchement Internet est inondé de désinformation et de personnes contournant les standards dès que ça corresponds à un truc « cool ». Bruce Lawson me rappelait l’existence des Web Standards Curriculum qu’Opera ont ouverts et soumis au W3C; mais ce n’est pas écrit pour un développeur d’aujourd’hui, c’est écrit pour des gens qui sont déjà bien avertis.

Troisièmement, nous avons besoin que les services de validation HTML/CSS marquent le manque de standards comme des erreurs. Si vous avez un préfixe -webkit- et pas la version non préfixée, c’est une erreur. Si vous avez un préfixe -webkit- mais pas la version -moz-, c’est un avertissement (idéallement une erreur). Au fond nous voulons faire du web un meilleur endroit, et ça n’arrivera que si on éduque.

Quatrièmement, arrêtons avec la minification des CSS. Je sais que ça va causer une controverse, mais on ne gagne que quelques Ko et on rends le débuggage de notre code plus difficile pour les gens. Et avant que quelqu’un ne me sorte « l’excuse des données sur mobile », je vous en réfère aux images dans le responsive design, et le fait que des sites mis en avant par des magazines importants atteignent maintenant 5 Mo à télécharger sur un mobile ! Le web a grandit basé sur la capacité des gens à inspecter du code, lire, apprendre et reproduire; revenons en aux bases.

Cinquièmement, nous avons besoin que le CSS Working Group avance plus vite. Foutrement plus vite ! Une partie des cartes de Apple/Google consiste à dire que le CSSWG (et tous les autres groupes de travail impliqués dans CSS et HTML5) sont tellement horriblement lents à standardiser quoi que ce soit que les gens n’ont pas d’orientation claire et unifiée. Cette excuse foireuse ne marchait pas pour Microsoft à l’époque, et elle ne marche pas non plus maintenant; mais ça ne veut pas dire qu’ils ont tort, mais indique juste le niveau de négligence dont ils veulent se décharger.

Enfin, nous devons pointer du doigt et balancer des noms. Aucun d’entre nous n’aiment cette idée, mais il le faut, désolé. C’est la seule façon pour que les gens fassent attention. Prenez le top 10 000 d’Alexa. Prenez le top 500 FTSE. Prendez le top 100 des agences numériques et parcourez les sites qu’elles ont réalisé. Croyez moi, il ne faudra que quelques messages du genre « Les sites réalisés par R/GA ne fonctionnent pas sur 250 millions d’appareils mobiles » et les choses changeront.

Je suis assez d’accord avec l’ensemble de ces points, en particulier le deuxième invitant à éduquer les développeurs web, comme je l’évoquais ici. Le 4ème point me semble assez futile. Et même si le dernier point et l’idée d’une chasse au sorcière (comme l’avais suggéré Daniel Glazman) me dérange profondément, je crains qu’il ne faille en arriver là pour que les choses changent.

  1. boblemarin, le

    Merci pour la traduction.
    La vidéo qui accompagne l’article original lui donne une puissance toute particulière (en plus de justifier son titre), tu pourrais peut-être l’ajouter ici aussi ? :)
    http://youtu.be/AIpkMg9sh6Q

  2. viki53, le

    Minifier le CSS n’a plus d’intérêt avec un bon débugger (du style l’outil Webkit sur Chrome et Safari), et personnellement le temps de chargement sur mobile ne me gène pas (je sais que je suis sur mobile, donc nécessairement ça prendra du temps).

    Balancer des noms ne servira à rien, c’est vrai. Au pire on verra que ceux qui font le plus de chiffre ne sont pas ceux qui respectent le mieux les standards. Et alors ? C’est le cas dans tous les domaines, pas seulement sur le Web.

    En revanche, arriver à une vraie standardisation, à un monde où les préfixes propriétaires ne sont plus nécessaires (voire inexistants) serait une bouffée d’air pur. Au final c’est du temps perdu, un copier-coller à modifier, des lignes de code répétitive. En Java on ne ré-écrit pas toute une classe d’interface graphique pour chaque plateforme. Pourquoi doit-on le faire en CSS pour chaque navigateur ?

    Si les acteurs du Web (le W3C, Mozilla, Opéra, Google, Apple, Microsoft…) travaillaient ensemble pour proposer un « moteur de rendu commun », ils pourraient plus facilement se concentrer sur les fonctionnalités autres du navigateur, et les développeurs verraient des progrès beaucoup plus significatifs se profiler à l’horizon.

  3. Alexandre B., le

    Je ne suis pas vraiment d’accord sur le point 4.
    Les outils de débugage sous Firefox ou Chrome, ou même ie, permette d’afficher clairement les propriétés CSS utilisées, et avec Firebug on peut même copier/coller ces règles proprement. Le fait que le code soit minifié ne facilte pas les choses certes, mais n’est pas impossible, surtout avec les bons outils.

    Le fait est que nous sommes au début du web mobile, même si certains diront le contraire, toute l’industrie de l’internet est jeune, et encore plus celle du mobile.

    Il existe des méthodes permettant de délivrer des images pour les devices mobiles.
    Les solutions existent.

    Sinon je suis assez d’accord aussi, tout n’est que question d’éducation.

  4. AkaiKen, le

    J’aime beaucoup le troisième point. Cela implique cependant que les validateurs soient toujours mis à jour suivant les sorties des navigateurs : si Firefox implémente une nouvelle propriété avec préfixe, après que Chrom(e|ium) l’ait fait, par exemple, il faut immédiatement que les validateurs le prennent en compte, et marquent un avertissement si on n’utilise que -webkit- (avertissement qui n’aurait pas eu de sens avant, puisque Chrom(e|ium) était le seul à implémenter cette propriété).

  5. Bartdude, le

    J’aime assez le point 2 personnellement. En effet, on trouve un peu tout et n’importe quoi sur le web, et même les infos de qualité peuvent vite devenir caduques avec l’évolution technologique. Un point de référence central évoluant en même temps que les standards me paraît donc nécessaire.

    Quant au dernier point… c’est pisser dans un violon. C’est pas le tout de crier, encore faut-il qu’il y ait quelqu’un qui écoute.

  6. Identitools, le

    Je ne suis pas d’accord non plus avec le 4ème point.
    Non seulement comme Alexandre B. l’a évoqué des outils de débogage existent sur les navigateurs mais j’aimerais souligner le fait que si l’on utilise un préprocesseur CSS comme Less ou Sass (Sass forever !) le problème ne se pose pas puisque l’on peut choisir entre une version minifiée ou « classique » à la compilation.

    Aussi, penser au web mobile dans le poids des pages c’est bien mais là ou je vis je télécharge à un grand maximum de 250ko/s donc c’est un problème encore d’actualité même pour les postes fixes.

    Quand aux autres points je suis plutôt d’accord. Joli article :)

  7. shavounet, le

    Le point 4 est plus vrai pour du JS à la rigueur. Je suis moyennement convaincu que ça soit utile, tout pareil que pour du CSS.

  8. bfontaine, le

    Pas d’accord avec le point 4, il existe une convention pour garder la lisibilité ET minifier: utiliser une version monStyle.css et monStyle.min.css identiques (en dehors de la minification du second fichier, évidemment). Comme ça, si je vais sur un site qui a une feuille de style en .min.css, je sais qu’en enlevant le « .min » de l’URL, j’arrive sur la version non minifiée, et donc lisible (idem pour les fichier JS). Exemple: bfontaine.net/cv/cv.min.css et bfontaine.net/cv/cv.css .