Compatibilité : oui mais non

Commentaires

• karl (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

• Stéphane (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

• karl (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

• 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à :)

  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

• karl (4 mars 2016)

  Soyons taquin ;)

  http://imgur.com/Y3HAu8V

  Répondre à karl

• Gaël Poupard (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

• Stéphane (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

• 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 :)

  Répondre à Stéphane