Pourquoi l’élément `html` n’est-il pas pris en charge à 100 % sur caniuse.com ?

 (anderegg.ca)
2 points par GN⁺ 2024-02-03 | 1 commentaires | Partager sur WhatsApp
  • CanIUse.com est un site qui suit la compatibilité des technologies web, mais le taux de prise en charge affiché pour l’élément de base html est de 97,34 %, ce qui soulève des questions sur l’interprétation de ce chiffre
  • Ce taux semble lié aux données de compatibilité MDN utilisées par CanIUse.com, et certains sous-éléments de la page de l’élément html paraissent l’influencer
  • Les éléments en cause sont l’attribut optionnel manifest et secure context required, tous deux non standardisés ou obsolètes
  • Le mélange entre navigateurs non pris en charge, navigateurs dont la prise en charge est inconnue et anciens navigateurs fait apparaître, même pour un élément de base comme html, un taux de prise en charge peu intuitif
  • Avec le critère « % of all tracked », on peut obtenir 99,98 % en ajoutant les navigateurs en support unknown, ce qui rend une erreur d’arrondi plus plausible, mais les chiffres de CanIUse.com doivent malgré tout être lus avec prudence

La question soulevée par les 97,34 % de prise en charge de html

  • CanIUse.com suit le taux d’adoption des navigateurs et la compatibilité des fonctionnalités web, et affiche sous forme chiffrée dans quelle mesure une fonctionnalité peut réellement être utilisée
  • Le taux de prise en charge de l’élément html est affiché à 97,34 %
    • C’est un chiffre inférieur à celui de l’élément audio
    • Les éléments a et p affichent eux aussi le même taux de prise en charge de 97,34 %
  • Le fait qu’un élément fondamental du web utilisé depuis très longtemps ne soit pas à 100 % montre qu’il faut aller au-delà d’un simple chiffre de compatibilité

Les sous-éléments visibles dans le tableau de compatibilité MDN

  • Une grande partie des données de CanIUse.com semble provenir de MDN
  • La page de l’élément html sur MDN contient une section de compatibilité navigateur
  • Dans ce tableau, deux éléments comportent de nombreux X rouges
    • L’attribut optionnel manifest
      • Il est obsolète
      • Il n’a jamais été standardisé
    • L’élément associé secure context required
  • Il est vrai que presque tous les navigateurs ne prennent pas en charge ces deux éléments, mais cela n’explique pas clairement à lui seul pourquoi le taux global de prise en charge de l’élément html descend jusqu’à 97,34 %

Anciens navigateurs et possibilité d’erreur d’arrondi

  • Certains navigateurs sont indiqués comme Support Unknown, et la somme actuelle de leur part d’usage est de 1,27 %
  • Android Browser 2.1–4.3 est indiqué comme ne prenant pas en charge l’élément html, mais sa part d’usage est de 0 %
    • Il est douteux que ces anciens navigateurs n’aient réellement pas pris en charge l’élément html
    • Il n’est pas clair non plus si une erreur d’arrondi pourrait faire passer 1,27 % à 2,66 %
  • En haut à droite sur CanIUse.com, si l’on change le critère à côté de « usage » pour « % of all tracked » et qu’on ajoute les navigateurs marqués « support unknown », on obtient 99,98 %
    • Avec ce critère, il est plus facile d’envisager que le chiffre actuel provienne d’une erreur d’arrondi
    • Cela dit, la manière dont les anciens navigateurs sont traités pour un élément fondamental comme html reste déroutante
  • CanIUse.com reste une ressource utile, mais les taux de prise en charge affichés doivent être lus en tenant compte à la fois du contexte et de la méthode de calcul

À lire aussi

1 commentaires

 
GN⁺ 2024-02-03
Avis sur Hacker News

  • CanIUse propose une option « % of all » juste au-dessus du pourcentage Global. Si l’on ouvre la roue dentée sur une page de fonctionnalité, le mode de calcul de l’usage est expliqué plus en détail. Par défaut, c’est All Users : l’usage de tous les navigateurs que caniuse ne suit pas est considéré comme non pris en charge. Si l’on passe à All tracked users, seuls les navigateurs suivis sont pris en compte, ce qui donne 98,71 %. Dans le graphique, la somme des navigateurs dont la prise en charge est Unknown est de 1,27 % ; si l’on ajoute 1,27 % à 98,71 %, on obtient 99,97999…, ce qui semble indiquer un effet d’arrondi. Le vrai problème est que ces navigateurs sont indiqués comme Unknown, alors qu’en pratique on peut probablement considérer qu’ils prennent en charge l’élément ``.

    • À en juger par les chaînes User-Agent « non réellement identifiées » qui apparaissent dans les journaux de requêtes de notre API SaaS, une bonne partie de ces 1,27 % de « navigateurs » sont très probablement toutes sortes de scrapers spécialisés arrivés là par hasard, en dehors de leur domaine habituel. On ne peut donc pas forcément supposer qu’ils savent analyser ``. Ce sont peut-être des scrapers JSON.
    • wget est beaucoup utilisé, et si on l’inclut, c’est une autre histoire. En regardant src/html-url.c, on voit qu’en réalité il ne prend pas du tout en charge `` et le traite comme une balise inconnue.

  • J’ai bloqué sur le fait que MDN signifiait autrefois Mozilla Developer Network, mais que désormais c’est simplement MDN ; j’ai cherché, sans réussir moi non plus à trouver le nom complet.

    • Ce changement a eu lieu vers 2017. Le nom Mozilla Developer Network était assez ambigu, et des sondages ainsi que des entretiens utilisateurs montraient qu’il prêtait à confusion. Les développeurs web pensaient qu’il s’agissait de ressources réservées aux développeurs Mozilla ; au début, c’était d’ailleurs largement le cas, donc ce n’était pas totalement faux. Pendant un temps, MDN contenait beaucoup de documentation liée à Mozilla en plus de la documentation de la plateforme web, mais en 2017 cette dernière représentait 95 % du trafic de MDN, et les ressources destinées aux développeurs Mozilla n’étaient plus son identité principale. Le nom a donc été changé en MDN Web Docs afin de refléter ce changement de priorité.
    • Ce changement s’est produit aux alentours du 15 août 2017. Je le sais parce que je suis tombé par hasard sur le moment où le branding avait changé, mais pas encore le contenu des pages. Voici le rapport de bug que j’avais soumis à l’époque : https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • J’aime bien appeler ce genre de chose un anachronym : cela donne l’idée d’un acronyme anachronique. À strictement parler, il s’agit plutôt d’un sigle que d’un acronyme, mais j’ai aussi écrit un article à ce sujet. https://simpsonian.ca/blog/anachronyms/
    • Il en reste quelques occurrences dans des pages annexes et du code d’exemple, mais c’est à peu près tout ce que j’ai trouvé. “will soon be a proud part of the Mozilla Developer Network (MDN)” — https://developer.mozilla.org/en-US/blog/mdn-observatory/ “Their brilliant but offbeat idea grew into today's Mozilla Developer Network” — https://developer.mozilla.org/en-US/docs/MDN/At_ten const heading = Mozilla Developer Network; — https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
    • Je me souviens qu’il y a quelques années, la documentation de Microsoft avait commencé à renvoyer vers celle de Mozilla. C’était peut-être lié au rebranding d’Edge. Si le nom a été changé en MDN au cours de cet accord, c’était peut-être pour éviter une confusion du genre « est-ce M(ozilla)DN ou M(icrosoft)DN ? », mais je n’en suis pas sûr.

  • Fait intéressant, j’ai entendu dire que les éléments et affichaient exactement le même taux de prise en charge de 97,34 %. Ces deux éléments utilisent eux aussi des données provenant de MDN, comme l’élément `` : https://caniuse.com/mdn-html_elements_a et https://caniuse.com/mdn-html_elements_p J’ai mis l’article à jour pour intégrer ce point.

  • Ce serait peut-être bien que CanIUse sépare html-manifest en tant que fonctionnalité distincte. Et je tiens aussi à redire que MDN est une ressource vraiment excellente.

  • La toute première page web n’utilise pas l’élément html. http://info.cern.ch/hypertext/WWW/TheProject.html

  • Est-ce que cela a un rapport avec le HTML valide minimal ? Il n’y a pas de balise HTML dedans.

    • Cela ne semble pas vraiment lié. `` affiche presque le même pourcentage : https://caniuse.com/mdn-html_elements_title Cela ressemble plutôt à une question de méthode de calcul pour les navigateurs dont on connaît l’usage, mais dont on n’a pas pu vérifier la prise en charge. À noter aussi que ce HTML n’est pas réellement valide : il est traité comme ayant un titre vide, or un titre vide n’est pas valide. En le remplaçant par quelque chose comme ., il passerait sans erreur.
    • Pourtant, il n’y a pas quand même une balise là-dedans ? Elle n’est simplement pas écrite explicitement et elle est donc déduite. Quel que soit le navigateur utilisé pour l’ouvrir, cette page contiendra une balise.
    • Dans un protocole où le titre peut être transmis autrement, comme l’en-tête Subject d’un e-mail, est optionnel. Le HTML valide le plus court n’est donc qu’un simple, mais seulement dans certains contextes précis.

  • Dire que « beaucoup de données du site viennent de MDN » est un peu ambigu. La matrice de prise en charge des fonctionnalités reliée à CanIUse vient du dépôt browser-compat-data de MDN. Les données sources pour les éléments HTML sont ici : https://github.com/mdn/browser-compat-data/blob/main/html/el... Mais ce dépôt ne contient pas les tests ni les informations d’usage que CanIUse cite pour calculer les taux de prise en charge ; il indique seulement quelles versions de navigateurs incluaient quelles fonctionnalités. CanIUse pointe aussi vers son propre dépôt, qui contient beaucoup de données : https://github.com/fyrd/caniuse Mais je n’ai pas trouvé de point d’entrée permettant de retrouver facilement d’où viennent les chiffres d’un élément précis. Les données y semblent elles aussi principalement organisées par fonctionnalité. La question plus exacte est de savoir d’où CanIUse tire les tests des éléments HTML et les chiffres d’usage, et c’est cela qui semble être le cœur du problème.

  • Le taux de prise en charge de l’élément `` ne devrait-il pas être au moins inférieur ou égal à celui de tous les autres éléments ?

    • Non. L’élément ne signifie pas « tout le HTML » ; ce n’est qu’un élément parmi d’autres, qui désigne simplement **l’élément racine du document**. Comme quelqu’un d’autre l’a écrit, il n’est même pas strictement nécessaire pour créer un document HTML valide sans erreur ; ce qu’il faut alors, c’est et un corps valide. Par analogie, la capacité à comprendre et analyser correctement le mot « English » dans le titre d’une dissertation est indépendante du fait de connaître le sens du mot anglais « fustigate ».

  • « Il n’y a donc pas de réponse claire. Si vous savez, dites-le ! »