Proposition de suppression des mentions de XSLT dans la spécification HTML

 (github.com/whatwg)
2 points par GN⁺ 2025-08-20 | 1 commentaires | Partager sur WhatsApp
  • Une Pull Request a été proposée pour supprimer les mentions liées à XSLT du document de standard HTML
  • L’auteur de la proposition explique que des bogues d’implémentation ont été signalés dans les principaux navigateurs comme Chrome, Firefox et Safari, et que des problèmes de tests et de documentation sont également en cours de traitement
  • Les opposants soulignent des problèmes de compatibilité avec les sites existants ainsi qu’un problème de lisibilité où les documents XML se casseraient si <?xml-stylesheet?> était supprimé
  • Certains développeurs insistent sur le fait que XSLT est encore utilisé dans les documents gouvernementaux, les flux RSS et les environnements embarqués
  • Des inquiétudes sont exprimées quant au fait que des décisions centrées sur les grands éditeurs de navigateurs puissent conduire à une réduction de l’ouverture du Web et de sa diversité historique

Aperçu de la Pull Request

  • Titre de la PR : Remove mentions of XSLT from the html spec
  • Auteur : mfreed7
  • Cible : whatwg/html:main
  • Issue associée : #11523
  • Des rapports de bogues d’implémentation existent pour Chromium, Gecko et WebKit
  • Des mises à jour sont prévues pour la documentation MDN et d’autres ressources associées comme HTML AAM

Principaux arguments d’opposition

gucci-on-fleek (2025-08-15)

  • Il faut tenir compte des statistiques d’usage et de la taille des sites web
    • Les grands sites peuvent être mis à jour, mais les petits sites et sites personnels ne sont parfois plus maintenus depuis des décennies, ce qui fait craindre une rupture de compatibilité permanente
  • Supprimer XSLTProcessor() ne limiterait qu’une fonctionnalité JS, mais supprimer <?xml-stylesheet?> provoquerait un problème où les documents XML ne s’afficheraient plus du tout
  • Alors que d’anciennes fonctionnalités HTML obsolètes (<font>, <align>, <xmp>) continuent encore de fonctionner, il s’agirait ici d’un changement sans précédent qui casse le document lui-même
  • Mise en avant du risque de bloquer l’accès à des ressources importantes comme d’anciennes archives ou des sites universitaires

nomis (2025-08-18)

jonsterling (2025-08-18)

  • Critique la réalité dans laquelle les éditeurs de navigateurs définissent de facto la plateforme web de manière monopolistique
  • Selon lui, XSLT contribue encore à des usages variés et créatifs du Web, et sa suppression risquerait d’affaiblir l’Open Web
  • Il insiste sur le principe selon lequel « le Web appartient à tout le monde » et sur la nécessité de respecter son histoire et sa diversité

Soutiens et suites prévues

  • domenic (2025-08-19) : réaction positive, en soulignant qu’il faudrait aussi mettre à jour les mentions de XSLT dans la spécification DOM
  • mfreed7 (2025-08-19) : répond qu’il soumettra également une PR séparée pour la spécification DOM

En résumé

  • La suppression de XSLT est proposée dans le cadre des efforts de simplification et de modernisation des navigateurs
  • Mais les opposants craignent une dégradation de la compatibilité des documents existants, de l’accessibilité des données gouvernementales et académiques, ainsi que de la diversité de l’Open Web
  • Le débat dépasse donc le simple choix technique pour toucher à une question plus philosophique : qui détient le pouvoir de décision sur les standards du Web

À lire aussi

1 commentaires

 
GN⁺ 2025-08-20
Avis sur Hacker News

  • Quelques points notables

    • Cette décision n’est pas une initiative unilatérale de Chrome, et on peut vérifier dans le suivi de l’issue ainsi que dans les comptes rendus des réunions de standardisation associées que des représentants de tous les principaux navigateurs ont exprimé leur soutien

    • Le point récent à l’ordre du jour a également été proposé par un ingénieur de Mozilla

    • Le dépôt d’une PR ne signifie pas qu’elle sera fusionnée immédiatement, et il reste encore pas mal de tâches non traitées

    • Mais dans une situation où plusieurs éditeurs de navigateurs sont d’accord, il est probable qu’elle soit fusionnée

    • L’issue qui examine la suppression de XSLT de la plateforme web n’est pas destinée à recueillir l’avis de la communauté, mais constitue une discussion pour les mainteneurs de la spécification HTML

    • Cette issue a été ouverte par un ingénieur de Chrome, mais le fait important est que des ingénieurs de Mozilla ont soulevé ce sujet à plusieurs reprises en réunion et qu’un consensus entre éditeurs existait déjà

    • Une faille de sécurité grave a déjà été mise au jour

    • Le mainteneur principal de libxslt a lui aussi directement démissionné

    • Le mot Chrome a été retiré du titre

    • Le titre soumis à l’origine était "Chrome intends to remove XSLT from the HTML spec"

    • D’après les données de télémétrie de Chrome, il existe en réalité très peu de sites web qui utilisent XSLT

    • On peut au moins confirmer par les données que cette proposition n’aurait pas d’impact majeur sur l’ensemble du web

    • Je suis un développeur qui a travaillé par le passé chez Mozilla et Google (équipe Chrome)

    • Je comprends que Chrome/Blink, Safari/Webkit et Firefox/Gecko soutiennent tous la suppression de XSLT, mais deux de ces projets manquent de ressources, et l’un d’eux a une forte tendance à imposer de nouvelles fonctionnalités

    • Les développeurs de Safari et Firefox ont aussi des raisons d’accueillir favorablement ce changement

    • La question importante n’est pas « est-ce que des personnes faisant autorité pensent que c’est une bonne idée », mais « est-ce que cette idée aura un impact négatif sur la plateforme web et sur des milliards d’utilisateurs »

    • Même si seulement 0,1 % de plusieurs milliards de personnes en dépendent, cela reste une échelle considérable

    • Si personne ne l’utilise, il n’y a aucune raison qu’un polyfill existe

    • Il n’est pas souhaitable d’imposer une logique de jeu à somme nulle où l’ajout d’une nouvelle fonctionnalité exigerait forcément la suppression d’une ancienne

    • Google choisit délibérément de ne pas assurer le support de XSLT alors même qu’il dispose de capitaux et d’effectifs suffisants

    • Il y a souvent eu des cas où quelque chose avançait rapidement dès lors que plusieurs éditeurs étaient d’accord

    • La suppression de confirm/prompt a suivi ce schéma, mais a finalement été reportée pour une durée indéterminée

    • Il existe chez Google un document officiel décrivant le processus de suppression de fonctionnalités affiliées
      Google feature removal doc

    • Le « soutien unilatéral des éditeurs » n’a pas correctement examiné l’usage réel

  • D’après les deux fils que j’ai lus, Google a demandé des retours, mais presque tous disaient « ne le faites pas »

    • Pourtant, Google a réagi en mode « merci pour vos avis, mais on va quand même le faire ! »

    • Si l’enjeu était vraiment la sécurité, il existait diverses alternatives, comme financer l’open source, remplacer la bibliothèque par une plus sûre, ou maintenir cela dans une sandbox JS, mais elles ont été pour la plupart ignorées

    • Il y a aussi eu des demandes répétées pour la prise en charge de versions récentes comme XSLT 3.0, sans suite

    • Bien que XSLT soit une technologie favorable au web ouvert, Google a réduit son support et l’a laissé à l’abandon depuis dix ans, puis a continué à tenter de le supprimer en invoquant la baisse de sa part d’usage

    • Alors que XSLT regagne récemment en popularité, on a l’impression d’une volonté de le tuer avant l’apparition de concurrents ouverts

    • Issue associée

    • Concernant l’affirmation selon laquelle beaucoup de retours disaient « ne le faites pas », le fil a été verrouillé tôt à cause de commentaires malveillants, d’insultes et de propos diffamatoires

    • Les avis du type « c’est une bonne idée » sont souvent moins exprimés, ce qui peut donner l’impression qu’il n’y a que de l’opposition

    • Tout le monde a adopté un ton extrême, le débat a été clôturé, et les participants l’ont en partie provoqué eux-mêmes

    • Si les avis disant « ne le faites pas » ne viennent pas d’utilisateurs réels ou ne peuvent pas expliquer pourquoi c’est indispensable, il est raisonnable que l’équipe de développement les ignore

    • Une demande de retours n’est pas un simple vote pour ou contre

    • Ce serait bien si l’on pouvait déplacer le support de XSLT 3.0 vers une sandbox JS/wasm

    • Il y aurait peut-être une légère perte de performance, mais on pourrait profiter des avantages des deux côtés

    • XML permet une intégration relativement aisée grâce à des caractéristiques comme les schémas de versionnement et les espaces de noms

    • Contrairement à des frameworks js comme Angular, il permet des contrats de données très fiables

    • Grâce à la maturité de l’écosystème XML, il existe de nombreux outils spécialisés, si bien qu’en pratique il n’est pas nécessaire de manipuler directement XML/XSD en texte brut

    • Google formule souvent les choses sous forme de « question » pour prévenir à l’avance de ce qui va arriver sur le web

  • Présentation d’anciens fils liés au sujet

  • Je me demande si un navigateur a réellement besoin d’un support intégré pour un moteur de templates donné (XSLT)

    • Ce n’est pas un moteur textuel comme Jinja, mais il peut aussi être réimplémenté en JS/wasm

    • Les navigateurs sont aujourd’hui trop lourds, et il est difficile de développer de nouveaux moteurs

    • J’aimerais qu’il existe un standard plus simple, avec juste l’essentiel pour des « navigateurs minimaux » (balises de base, mise en page, etc.)

    • WebAudio, Canvas, etc. pourraient aussi être implémentés sous forme de modules wasm (et cela éviterait aussi le fingerprinting)

    • XSLT est une « spécification » pour un moteur de templates, pas un moteur particulier, et il existe plusieurs implémentations

    • Mozilla utilise transformiix au lieu de libxslt

    • Jinja se limite à du traitement de texte simple, tandis que XSLT opère au niveau des nœuds et lui est largement supérieur

    • Une transformation en JS est bien plus lente qu’une transformation XSLT native, et la mise en cache des résultats y est aussi plus difficile

    • Je comprends le point de vue qui considère XSLT comme dépassé, mais cela a été une arme secrète redoutablement efficace en matière de performances pendant vingt ans

    • Google finira probablement par tenter de masquer le problème avec une alternative du type AMP

    • Si les navigateurs sont lourds, c’est la faute de Google

    • XSLT est un langage (une spec), pas un moteur

    • Le fait de changer son implémentation en JS/wasm relève d’un choix d’implémentation interne, pas de ce qui se produit lorsqu’on retire le langage de la plateforme web

    • L’audio et le canvas sont des capacités d’E/S fondamentales du navigateur ; les déplacer vers wasm poserait de graves problèmes de performances et de compatibilité

    • Une partie de l’audio pourrait sans doute être déplacée dans un blob wasm, mais transférer l’ensemble serait difficile

    • Le contexte canvas, WebGL, etc. reposent sur une intégration directe avec le GPU, ce qui n’est pas réalisable en wasm

    • En fin de compte, ce sont déjà quasiment des API primitives de base, donc un domaine sur lequel on ne peut pas transiger

    • L’idée d’empaqueter un ancien code XSLT dans wasm pour préserver la compatibilité sans casser les vieux sites a aussi été discutée

    • Cela a bien été examiné en interne, mais il a été décidé de ne pas le faire

    • Je pense que des fonctionnalités très marginales et éloignées du cœur du web peuvent être candidates à la suppression

    • En revanche, je ne soutiens pas l’usage des vulnérabilités de sécurité comme justification

    • Sans même avoir vérifié s’il existe un paquet memory-safe, l’argument manque de force

    • Certains avancent un taux d’usage réel autour de 0,001 %

  • Rompre la promesse de base de la spec HTML est quelque chose d’extrêmement grave

    • Il est même surprenant que la discussion n’aborde pas ce point plus en profondeur

    • HTML représentait la promesse « ceci est du HTML, vous pouvez lui faire confiance », mais cela devient désormais « c’est du HTML pour l’instant, sans garantie que cela le reste à l’avenir »

    • Si l’on suit la logique de suppression de XSLT, d’autres technologies anciennes pourraient elles aussi continuer à être retirées

    • Au final, c’est une proposition visant à couper la « longue traîne » du web

    • Il faut aussi réfléchir au fait que les nombreuses technologies web ajoutées par la suite deviendront elles aussi une longue traîne, créant encore plus de futures candidates à la suppression

    • Pour ce qui est du support des anciens médias et logiciels, je pense qu’il arrive forcément un moment où il faut passer par le portage, l’émulation, l’archivage, etc.

    • Il faut trouver un équilibre entre laisser suffisamment de temps et d’outils pour s’adapter au changement, et éviter l’accumulation progressive de complexité

    • En regardant les passages supprimés dans la PR réelle, il ne semble pas y avoir dans HTML de règle explicite exigeant le support de XSLT

    • La réaction importante paraît surtout venir de la question du support par les navigateurs

    • La PR elle-même est étonnamment courte

    • En définissant HTML comme un « Living Standard », WHATWG en a fait en pratique non plus un standard d’implémentation, mais un moyen pour les éditeurs de navigateurs de partager l’état de ce sur quoi ils travaillent actuellement

    • C’est aussi pour cela que des désignations de version comme HTML5 ont disparu, au profit du seul terme « HTML »

    • Living Standard FAQ

    • HTML standard FAQ

    • Ironiquement, Google est aussi l’exemple type de l’entreprise qui a poussé une quantité énorme de fonctionnalités dans les specs HTML/CSS/des navigateurs

    • Si Google avait défendu de manière cohérente l’idée que « les navigateurs doivent rester légers et les choses bizarres doivent être laissées aux bibliothèques JS », cette mesure aurait été plus compréhensible, mais ce n’est pas du tout le cas

  • Depuis la suppression du support FTP, le sort de XSL est déjà écrit

    • Les navigateurs tendent à donner la priorité absolue à la réduction de la surface d’attaque

    • Je pense que les prochains candidats à la suppression seront des fonctionnalités liées à XML comme les attributs d’animation SVG SMIL ou MathML

    • Fil associé

    • SMIL permet de contrôler des animations séquentielles en fonction de moments précis de début et de fin, alors que les animations CSS sont encore insuffisantes sur ce point

    • En dehors du calcul de timing, CSS n’offre pas vraiment de solution

    • Chromium a lui aussi, à une époque, affiché sa volonté de supprimer SMIL, mais c’était trop prématuré car CSS n’était pas suffisant

    • À la suite de cela, diverses documentations liées à SMIL sont restées abandonnées sans mise à jour

    • J’aimerais poser la question de savoir si réduire la surface d’attaque est vraiment une bonne ou une mauvaise chose

    • Les ingénieurs et les utilisateurs ordinaires n’ont pas forcément les mêmes priorités

    • Je me demande quand la suppression de la fonctionnalité FTP a eu lieu

    • Il me semble qu’on peut encore accéder à ftp:// dans la barre d’adresse

  • Les implémentations XSLT de Blink et WebKit sont très inefficaces

  • Cette décision est regrettable, mais il est encore plus regrettable qu’aucun effort n’ait été consacré à une intégration plus moderne de XSLT

    • Son usage était peu pratique, mais avec une petite évolution supplémentaire dans le navigateur, il aurait pu devenir un concurrent sérieux de frameworks comme React

    • Sans la complexité imposée par les grandes entreprises, XML était en soi un standard très puissant et une technologie remarquable

    • J’aimais vraiment pouvoir utiliser XSLT pour transformer directement de petits fichiers xml/des données simples en html

    • S’il y avait juste eu une petite fonctionnalité de plus pour afficher différemment les éléments sélectionnés, on aurait pu envisager de nombreux usages, y compris pour des documents statiques, ce qui est dommage

  • Il est dit que @whatwg a verrouillé cette issue en la réservant aux collaborateurs, au motif que la discussion « s’était échauffée »

    • À mes yeux, cela paraissait pourtant assez raisonnable et calme, ce qui fait se demander si le seuil de ce qui est jugé « échauffé » ne varie pas selon qu’on soit favorable ou non à un certain éditeur

    • L’expression « c’est devenu trop animé » est souvent interprétée comme voulant dire qu’on ne veut pas gérer les avis opposés

    • C’est pareil dans d’autres communautés comme Reddit

    • En réalité, l’unique commentaire resté en dessous est celui d’un développeur de Google Chrome disant en substance « beau travail »

    • C’est un peu gênant à voir

    • Il est fait mention de cas où des insultes agressives, des théories du complot et des messages politiques ont afflué dans l’issue tracker

    • Dans ces conditions, toute discussion productive devient impossible et les mainteneurs du dépôt n’ont d’autre choix que d’interrompre rapidement le débat

    • J’ai entendu dire que la décision de verrouiller la discussion sur ce dépôt avait en réalité été prise par un employé d’Apple

    • Mais les gens en attribuent la responsabilité à l’employé de Google qui avait ouvert cette issue

    • Google a récemment mis en avant l’idée de recueillir l’avis de la communauté dans le cadre d’une discussion ouverte, mais cherche ensuite à imposer sa décision en ignorant tous les retours

    • Issue associée

  • Il faut réfléchir plus largement aux anciens éléments du web

    • Dans mon cas, il y a une vraie valeur au fait que d’anciennes pages web continuent à fonctionner correctement

    • Grâce à la compatibilité maintenue par HTML/JS, même des pages vieilles de plusieurs décennies fonctionnent encore très bien du moment qu’on leur ajoute un certificat TLS

    • Mais il n’est pas non plus possible de prendre en charge éternellement toutes les technologies héritées

    • Flash aussi a fini par basculer vers une expérience de jeux et de sites nostalgiques via un émulateur (Ruffle)

    • À long terme, utiliser un navigateur dédié ou un émulateur spécialisé dans les anciens rendus peut aussi constituer une alternative

    • Une extension polyfill XSLT existe déjà pour cela

    • Chrome ne souhaite pas la distribuer officiellement ni en assurer la maintenance

    • La situation est très similaire à celle de Ruffle