nota-bene.org > Sur le web > Compatibilité : oui mais non

Compatibilité : oui mais non

À propos de cet article

Un article de Stéphane

Publié le 3 mars 2016

URL courte : http://nota-bene.org/1106

8 commentaires

Mozilla vient de régler un « bug qui n’en est pas un » qui arrivait avec les sites truffés de règles spécifiques à Webkit.

Karl conclut :

In the end, the users deserve to have the right experience. The same way we recover from Web sites with broken HTML, we need to make the efforts to help users have a usable Web experience.

The battle is not over. Web sites still need to be fixed.

Karl sait évidemment toutes les raisons qu’ont les professionnels de ne pas vouloir faire ça, il les liste d’ailleurs plus haut dans cet article (et les défend souvent).

Mais là il ne s’agit pas du tout de la question du comportement standard d’un navigateur. La règle de base du comportement d’un navigateur c’est ça :

To facilitate experimentation and interoperability between implementations of various versions of HTML, the installed base of HTML user agents supports a superset of the HTML 2.0 language by reducing it to HTML 2.0 : markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization. Undeclared attributes are treated similarly. The entire attribute specification of an unknown attribute (i.e., the unknown attribute and its value, if any) should be ignored. On the other hand, references to undeclared entities should be treated as data characters.

En gros si tu as la flemme de lire, ami lecteur : ce qu’un navigateur ne comprend pas, il doit l’ignorer et traiter le reste du mieux qu’il peut [1]. Et c’est exactement ce qu’a fait Firefox jusque-là.

Et mieux (ou pire) encore dans la spec HTML 2 :

Information providers are warned that this convention is not binding : unspecified behavior may result, as such markup does not conform to this specification.

La spec elle-même dit en substance que si le développeur fait n’importe quoi, il faut s’attendre à ce que des choses cassent très probablement.

Ce que Mozilla tente de faire ici, c’est de compenser la très mauvaise conception des sites web par une interprétation, disons, très courtoise des bêtises qu’auront faites certains intégrateurs. C’est gentil pour l’utilisateur mais contre-productif pour le Web.

C’est ce que Microsoft a fait, il y a longtemps, avec Internet Explorer. Combien d’années leur a-t-il fallu pour faire machine arrière ? Tout le monde, au final, l’a subi : les développeurs du navigateur, les intégrateurs, et même les utilisateurs parce qu’on a dû subir des décalages par rapport aux recommandations pendant des années et des années, avec parfois impossibilité de mettre à jour le navigateur de peur (justifiée) de casser les services.

Le loup, la bergerie, tout ça…


Notes

[1J’ai trouvé cette référence dans le précieux livre d’Aaron Gustafson, Adaptive Web Design, second edition dont je vous reparlerai.


Commentaires

    • 3 mars 2016

    En fait Microsoft, ne fait pas machine arrière, puisqu’ils ont sensiblement fait la même chose pour pouvoir exister avec le nouveau moteur Edge qui implémente aussi les propriétés WebKit.

    Tout aussi problématique, Safari et Chrome ne peuvent pas eux-même retirer les propriétés WebKit puisqu’ils casseraient les sites Web. 20% de sites mobile au Japon et en Chine par exemple.

    HTML n’est pas tout à fait le bon exemple. Mais tu pourrais prendre XHR par exemple (créé par Microsoft) et rétroactivement implémenté par les autres.

    Ou encore innerText qui n’était pas implémenté depuis des années dans Firefox (mais implémenté dans WebKit et dans Blink et dans le vieux Presto avant). La propriété standard est textContent. Les "bons" sites faisaient alors textContent || innerText pour tester. Et puis tous les autres sites qui s’en moquaient parce que leur part de marché de Firefox est à moins de 1%, donc résultant en sites brisés.

    On ne parle pas de problèmes cosmétiques.
    http://www.la-grange.net/2015/12/09/geckit

    Cela m’embête beaucoup de voir Firefox implémenter ceci, mais qu’elle est l’alternative viable. Parce que droit dans ces bottes, cela ne marche pas non plus. ^_-

    Oui c’est mal, maintenant comment avançons nous vers une solution ?

    Répondre à karl

    • 4 mars 2016

    karl : Je sais que ça t’embête beaucoup, et tu te doutes bien que je n’en ai pas après toi mais après cette situation.

    Des éléments de réflexion pour moi :

    • Un jour Netscape a dit que si les balises de tables n’étaient pas correctement fermées, il arrêterait de les afficher. Tout le monde a vite obéi. Mozilla objectera avec raison qu’il était à l’époque majoritaire.
    • Tu cites XHR et innerText :
      • XHR est une révolution technique, pas une implémentation spécifique, « en test ».
      • innerText est une question de sémantique. Effectivement dans ce second cas il s’agit d’un abus un peu plus manifeste des concurrents à Firefox, et il y a eu un alignement au standard de facto. Paving the cowpath me semble bien être la façon moderne d’intégrer ce qui est fait dans le monde en général à l’intérieur d’une spécification qui évolue.

    Soit.

    Ce qui me chagrine ce n’est pas qu’on prenne ce qui marche dans un autre navigateur, au contraire. Dans un monde où le code est ouvert c’est même plutôt rassurant, voire réjouissant, de voir chacun prendre le meilleur de ce qu’inventent les autres et de construire dessus.

    Ici nous avons un détournement pur et simple des préfixes vendeur (je n’ai pas de traduction de vendor prefixes, pardon pour l’anglicisme mal traduit). Dans ton article Geckit tu cites l’exemple de propriétés CSS -moz-* qui ne marchent pas avec le moteur Gecko d’aujourd’hui, et oui, c’est tout à fait satisfaisant que ça ne marche pas, les préfixes vendeur ne sont que des méthodes d’expérimentation avant décision consensuelle sur l’impémentation finale.

    Inscrire dans la durée la prise en compte, dans d’autres navigateurs que Webkit, de préfixes -webkit-* c’est les pérenniser, et même les empêcher de changer. C’est briser le contrat qui nous lie avec les implémenteurs et avec les rédacteurs des spécifications. D’une certaine manière, c’est aussi briser le contrat de confiance qui lie les uns et les autres avec les intégrateurs.

    Je ne dis pas que j’ai une solution toute faite, je déplore simplement, sur mon banc, comme un vieux appuyé sur sa canne :

    • d’une part que notre communauté n’ait jamais assez de poids dans l’enseignement des pratiques et des contrats d’implémentation (mais le sujet est encore plus douloureux dès qu’il s’agit de regarder de près l’accessibilité —ou, le plus souvent, la non-accessibilité— des sites) ;
    • d’autre part la piètre culture de bon nombre des gens qui font des sites web.

    Un début de solution, peut-être : nos navigateurs embarquent suffisamment d’intelligence, pour, par exemple, calculer le nombre de propriétés préfixées dont l’équivalent standard n’est pas présent, et pour afficher un message disant en substance « ce site risque de mal s’afficher parce qu’il ne respecte pas une approche standard. » Ils savent déjà m’alerter sur les risques de HTTPS vs. HTTP, sur les permissions que je donne, etc. Ainsi le poids du « mauvais » rendu serait plus équitablement partagé entre le navigateur et le site web lui-même.

    Et, en tout cas, ce n’est pas un « bug » de Firefox, et il n’avait pas besoin d’être « fixé ». C’est cette sémantique, peut-être, qui m’a heurté au premier chef.

    Répondre à Stéphane

    • 4 mars 2016

    Stéphane : tu oublies un participant dans l’équation, ici

    > Un début de solution, peut-être : nos navigateurs embarquent suffisamment d’intelligence, pour, par exemple, calculer le nombre de propriétés préfixées dont l’équivalent standard n’est pas présent, et pour afficher un message disant en substance « ce site risque de mal s’afficher parce qu’il ne respecte pas une approche standard. »

    * Les implémenteurs par centaines
    * Les développeurs de sites Web par milliers
    * Les utilisateurs par millions/milliards

    Des messages d’avertissements, ils existent déjà au moins dans Firefox (developer tools) et parfois dans Chrome pour certaines choses, mais bien moins et entre les deux pour Safari. Les outils existent donc en partie, tu peux rajouter PostCSS, etc.

    Tu disais dans l’article "C’est gentil pour l’utilisateur mais contre-productif pour le Web."

    Donc ici tu pars du principe que si les implémenteurs font le travail nécessaire d’avertissement, que si les développeurs sont avertis sur le long terme, cela va s’améliorer. Dans la situation actuelle du marché, les deux seuls navigateurs capables de faire bouger les choses seraient Safari et Chrome.

    Les avertissements ne servent pas à grand chose en l’occurence, puisque les développeurs les ignorent déjà (sauf bien sûr les bons artisans). Donc disons, imaginons que les implémenteurs de Chrome disent, nous allons volontairement casser tous les sites dans 6 mois en enlevant le support de "display : -webkit-box ;"

    Imagine la levée de boucliers, ce n’est pas la même chose que l’exemple du table dont le comportement était le même depuis le début. En remontant les pendules, si tu veux réaligner l’exemple, il faudrait dire : Netscape supportait les tables non fermées et puis un jour, il décide d’être plus strict et d’obliger à fermer les tables. Imagine que de nombres de sites que tu réalises ou que tu utilises ne fonctionnent plus du jour au lendemain. (Note que personnellement, je serais assez pour mais je suis suffisamment geek pour comprendre et accepter que les sites soient tous pêtés.)

    Et tout cela bien entendu sans parler des sites non maintenus (legacy) qui ne seront jamais modifiés mais rendus illisibles.

    Donc il y a ce que nous devons faire pour le moment pour que le Web fonctionne partout. Et ce que nous apprenons pour éviter que cela se reproduise. Les -vendor- étaient une bonne intention mais pas la façon dont ils ont été implémentés dans les navigateurs. Il y a des discussions pour changer cela. Cela implique aussi les propriétés du DOM.

    Répondre à karl

    • 4 mars 2016

    >Et, en tout cas, ce n’est pas un « bug » de Firefox, et il n’avait pas besoin d’être « fixé ». C’est cette sémantique, peut-être, qui m’a heurté au premier chef.

    hehe. Bugzilla, tout s’appelle un Bug. Sur Github, tout s’appelle une issue. Que ce soit feature, discussion ou vrai bug. Et quand il est fermé dans Bugzilla, le statut est RESOLVED. FIXED. C’est la sémantique du logiciel dont tu te plains là sourire

    Maintenant si tu dis qu’il n’aurait pas du tout fallu implémenter tout cela. C’est une position possible mais qui a son lot de conséquences.

    Répondre à karl

    • 4 mars 2016

    Soyons taquin clin d'œil

    View post on imgur.com

    <script async src="//s.imgur.com/min/embed.js" charset="utf-8"></script>

    Répondre à karl

    • 4 mars 2016

    Ta dernière idée dans ce commentaire est excellente et aurait le mérite d’attirer l’attention du grand public (et par extension des clients et décideurs) sur l’existence de bonnes pratiques.

    Et à nouveau ça me rappelle mon vieil article (http://www.ffoodd.fr/css-experienceinherit/). À cette époque seul IE cassait le site quand le document n’était pas valide… et mon stagiaire a pris ça pour un bug.

    Ce(s) métier(s) sont vraiment complexes et profonds. Bien plus qu’il n’y parait pour les nouveaux arrivants.

    Répondre à Gaël Poupard

    • 4 mars 2016

    Les avertissements ne servent pas à grand chose en l’occurence, puisque les développeurs les ignorent déjà

    Oui, c’est bien triste. C’est tout à fait ce que je déplore.

    Répondre à Stéphane

    • 4 mars 2016

    karl : Oui, j’ai quelques erreurs CSS. Mais elles ne cassent aucun navigateur, elles sont identifiées comme "non critiques" par le maître des lieux pour cette raison, qui par ailleurs déplore l’outil qui a compressé ses CSS (un truc en PHP adjoint à Spip) qui, à la base, étaient valides et qui s’est promis pour la prochaine refonte de ne pas garder ledit outil, puisque maintenant Sass est mon sauveur sourire

    Répondre à Stéphane

Qui êtes-vous ?
Votre message
  • Pour créer des paragraphes, laissez simplement des lignes vides. Tous les liens sortants comporteront un attribut rel="nofollow". Merci de ne pas spammer.

Ceci est la version Bureau Afficher la version Mobile