Publié le 29 octobre 2025
Chrome prévoit d'abandonner et de supprimer XSLT du navigateur. Ce document explique comment migrer votre code avant la suppression fin 2026.
Chromium a officiellement abandonné XSLT, y compris l' XSLTProcessor et l'instruction de traitement XSLT. Nous prévoyons de supprimer la compatibilité à partir de la version 158 (17 novembre 2026). Les Firefox Firefox WebKit WebKit ont également indiqué qu'ils prévoyaient de supprimer XSLT de leurs moteurs de navigateur. Ce document fournit un historique et un contexte, explique comment nous supprimons XSLT pour rendre Chrome plus sûr et fournit une méthode de migration avant la suppression de ces fonctionnalités du navigateur. Pour obtenir les dernières mises à jour, consultez également l' entrée État de la plate-forme Chrome.
Qu'est-ce qui est supprimé ?
Deux API du navigateur implémentent XSLT, et les deux sont supprimées :
- La
XSLTProcessor
XSLTProcessor (par exemple,
new XSLTProcessor()). - L'instruction de traitement
XSLT
(par exemple,
<?xml-stylesheet type="text/xsl" ... ?>).
Chronologie pour Chrome
Voici le plan de Chrome :
- Chrome 142 (28 octobre 2025) : ajout de messages d'avertissement anticipé à la console Chrome.
- Chrome 143 (2 décembre 2025) : abandon officiel de l'API. Des messages d'avertissement d'abandon commencent à s'afficher dans la console et dans Lighthouse.
- Chrome 145 (2 décembre 2025 Canary) : les versions Canary, Dev et bêta commencent à désactiver XSLT par défaut, à titre d'avertissement anticipé.
- Chrome 146 (10 mars 2026) : règle d'entreprise mise en ligne à des fins de test. Cela permet aux entreprises de tester la désactivation anticipée de XSLT et de continuer à utiliser des fonctionnalités après leur date de suppression.
- Chrome 152 (25 août 2026) : mise en ligne de l'essai Origin Trial (OT) à des fins de test. Cela permet aux sites de continuer à utiliser des fonctionnalités après leur date de suppression.
- Chrome 158 (17 novembre 2026) : XSLT ne fonctionne plus dans les versions stables pour tous les utilisateurs, à l'exception de ceux qui participent à l'essai Origin Trial ou qui utilisent la règle d'entreprise.
- Chrome 176 (17 août 2027) : l'essai Origin Trial et la règle d'entreprise ne fonctionnent plus. XSLT est désactivé pour tous les utilisateurs.
Qu'est-ce que XSLT ?
XSLT, ou Transformations de langage de feuille de style extensible, est un langage utilisé pour transformer des documents XML, généralement dans d'autres formats tels que HTML. Il utilise un fichier de feuille de style XSLT pour définir les règles de cette conversion et un fichier XML contenant les données utilisées comme entrée.
Dans les navigateurs, lorsqu'un fichier XML est reçu et qu'il est lié à une feuille de style XSLT, le navigateur utilise les règles de cette feuille de style pour réorganiser, mettre en forme et convertir les données XML brutes en une page structurée (souvent HTML) qui peut être affichée pour l'utilisateur.
Par exemple, une feuille de style XSLT peut prendre l'entrée XML suivante :
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
et cette feuille de style XSL :
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/page/message">
<body>
<p>Message: <xsl:value-of select="."/></p>
</body>
</xsl:template>
</xsl:stylesheet>
et les traiter dans ce code HTML que le navigateur peut afficher : HTML
<body>
<p>Message: Hello World.</p>
</body>
En plus de l'instruction de traitement XSL présentée dans l'exemple précédent, il existe également l' XSLTProcessor API JavaScript qui peut être utilisée pour traiter des documents XML locaux avec des feuilles de style XSLT locales.
Historique de XSLT
Le World Wide Web Consortium (W3C) a recommandé XSLT le 16 novembre 1999 comme langage permettant de transformer des documents XML dans d'autres formats, le plus souvent HTML pour l'affichage dans les navigateurs Web. Avant la recommandation officielle 1.0, Microsoft a pris une initiative précoce en fournissant une implémentation propriétaire basée sur un projet de travail du W3C dans Internet Explorer 5.0, sorti en mars 1999. Conformément à la norme officielle, Mozilla a implémenté la compatibilité native avec XSLT 1.0 dans Netscape 6 fin 2000. D'autres navigateurs courants, dont Safari, Opera et plus tard Chrome, ont également intégré des processeurs XSLT 1.0 natifs, ce qui a fait des transformations XML-HTML côté client une technologie Web viable au début des années 2000.
Le langage XSLT lui-même a continué d'évoluer, avec la sortie de XSLT 2.0 en 2007 et de XSLT 3.0 en 2017, qui ont introduit des fonctionnalités puissantes telles que les expressions régulières, des types de données améliorés et la possibilité de traiter JSON. Cependant, la compatibilité avec les navigateurs a stagné. Aujourd'hui, tous les principaux moteurs de navigateur Web ne fournissent qu'une compatibilité native avec la version d'origine de XSLT 1.0 de 1999. Ce manque d'évolution, associé à l'essor de l'utilisation de JSON comme format de transmission et des bibliothèques et frameworks JavaScript (comme jQuery, React et Vue.js) qui offrent une manipulation et une création de modèles DOM plus flexibles et puissantes, a entraîné une baisse significative de l'utilisation de XSLT côté client. Son rôle dans le navigateur Web a été largement supplanté par ces technologies basées sur JavaScript.
Pourquoi XSLT doit-il être supprimé ?
L'inclusion continue de XSLT 1.0 dans les navigateurs Web présente un risque de sécurité important et inutile. Les bibliothèques sous-jacentes qui traitent ces transformations, telles que libxslt (utilisée par les navigateurs Chromium), sont des codebases C/C++ complexes et vieillissantes. Ce type de code est connu pour être particulièrement exposé à des failles de sécurité liées à la mémoire telles que les dépassements de tampon, qui peuvent entraîner l'exécution de code arbitraire. Par exemple, les audits de sécurité et les outils de suivi des bugs ont identifié à plusieurs reprises des failles de gravité élevée dans ces analyseurs (par exemple, CVE-2025-7425 et CVE-2022-22834, toutes deux dans libxslt). Étant donné que XSLT côté client est désormais une fonctionnalité de niche rarement utilisée, ces bibliothèques font l'objet de beaucoup moins de maintenance et d'examens de sécurité que les moteurs JavaScript principaux. Pourtant, elles représentent une surface d'attaque directe et puissante pour le traitement de contenus Web non fiables. En effet, XSLT est à l'origine de plusieurs failles de sécurité récentes très médiatisées qui continuent de mettre en danger les utilisateurs de navigateurs. Les risques de sécurité liés au maintien de cette fonctionnalité obsolète et fragile dépassent de loin son utilité moderne limitée.
De plus, l'objectif initial de XSLT côté client (transformer des données en HTML affichable) a été supplanté par des API JavaScript plus sûres, plus ergonomiques et mieux entretenues. Le développement Web moderne repose sur des éléments tels que l'API Fetch pour récupérer des données (généralement JSON) et l'API DOMParser pour analyser en toute sécurité des chaînes XML ou HTML dans une structure DOM au sein du bac à sable JavaScript sécurisé du navigateur. Les frameworks tels que React, Vue et Svelte gèrent ensuite le rendu de ces données de manière efficace et sécurisée. Cette chaîne d'outils moderne est en développement actif, bénéficie de l'investissement massif dans la sécurité des moteurs JavaScript et est utilisée par pratiquement tous les développeurs Web aujourd'hui. En effet, seulement 0,02% environ des chargements de pages Web utilisent XSLT aujourd'hui, et moins de 0,001% utilisent des instructions de traitement XSLT.
Il ne s'agit pas d'une action propre à Chrome ou Chromium : les deux autres principaux moteurs de navigateur prennent également en charge la suppression de XSLT de la plate-forme Web : WebKit, Gecko.
Pour ces raisons, l'abandon et la suppression de XSLT réduisent la surface d'attaque du navigateur pour tous les utilisateurs, simplifient la plate-forme Web et permettent de concentrer les ressources d'ingénierie sur la sécurisation des technologies qui alimentent réellement le Web moderne, sans perte pratique de fonctionnalités pour les développeurs.
Améliorer la sécurité de l'analyse XML
Comme pour les graves problèmes de sécurité dans libxslt, des problèmes de sécurité graves ont récemment été signalés concernant libxml2, qui est utilisé dans Chromium pour l'analyse, la sérialisation et le test de la bonne formation du code XML. Pour résoudre les futurs problèmes de sécurité liés à l'analyse XML dans Chromium, nous prévoyons de supprimer progressivement l'utilisation de libxml2 et de remplacer l'analyse XML par une bibliothèque d'analyse XML sécurisée en mémoire écrite en Rust. Il est important de noter que nous ne supprimerons pas XML du navigateur. Seul XSLT est envisagé pour la suppression. Nous avons l'intention de nous assurer que le remplacement de libxml2 est entièrement transparent pour les développeurs Web.
XML + CSS ne sont pas supprimés
Il est important de distinguer l'abandon de XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) de l'
<?xml-stylesheet ... ?> instruction de traitement elle-même, qui reste compatible
lorsqu'elle est utilisée avec CSS. Vous pouvez toujours utiliser l'instruction de traitement avec
type="text/css" pour appliquer des règles de mise en page et de conception standard à vos données brutes,
comme vous le feriez avec HTML. Exemple :
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
Comment procéder ?
Il existe plusieurs méthodes de migration.
JSON
Pour les sites entièrement basés sur XML et XSL, il n'existe pas de méthode unique pour effectuer la transition. Les options de migration incluent le déplacement du pipeline de traitement XSLT côté serveur et l'envoi du code HTML rendu au client, ou la migration des points de terminaison d'API XML côté serveur vers JSON, et l'exécution du rendu côté client à l'aide de JavaScript pour transformer JSON en DOM HTML et CSS.
XSLT côté client en JavaScript
Il existe quelques bibliothèques XSLT côté client (basées sur JavaScript), mais la plus grande est de loin celle produite par Saxonica (consultez la documentation complète de Saxonica). L'implémentation va bien au-delà de l'implémentation XSLT 1.0 dans les navigateurs Web, en implémentant une compatibilité complète avec la dernière norme v3.0et, à terme, avec la norme v4.0 en cours de développement.
Polyester
Il existe un polyfill qui tente de permettre au code existant, qui dépend des implémentations XSLT 1.0 des navigateurs Web, de continuer à fonctionner, sans utiliser les fonctionnalités XSLT natives du navigateur. Le polyfill se trouve situé sur GitHub.
Le polyfill contient un remplacement polyfill fonctionnel basé sur WASM pour la classe XSLTProcessor. Le code JavaScript existant peut donc continuer à fonctionner tel quel :
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Le polyfill fournit également une fonction utilitaire automatique pour remplacer facilement les documents XML qui utilisent des instructions de traitement XSLT :
Pour un fichier demo.xml d'origine comme celui-ci :
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Une ligne peut être ajoutée pour appeler le polyfill et transformer le document avec la feuille de style XSLT référencée :
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
Dans ce cas, le nouvel élément <script> charge le polyfill, qui détecte le
type de document XML et l'instruction de traitement XSLT, puis le charge de manière transparente
, en remplaçant le document.
Extension
Il existe également une extension Chrome qui peut être ajoutée aux navigateurs compatibles. Elle appliquera le même polyfill XSLT à toutes les pages XML brutes contenant des instructions de traitement XSLT ou des appels à XSLTProcessor. Cela peut être utilisé pour les applications où le code XML ou XSLT source ne peut pas être modifié, afin de maintenir la fonctionnalité.
En particulier, lorsque XSLT est désactivé, Chrome affiche désormais une bannière d'avertissement qui renvoie directement à une page de recherche d'extensions, afin d'aider les utilisateurs à trouver une extension :
Cas d'utilisation spécifiques
Lors de la discussion sur les normes HTML standards, plusieurs cas d'utilisation concrets ont été identifiés. Cette section aborde chacun d'eux en particulier, afin de recommander des solutions aux développeurs qui publient aujourd'hui des ressources XML utilisant XSLT.
Flux RSS et Atom
Dans de nombreux flux RSS ou Atom existants, XSLT est utilisé pour rendre les flux XML bruts lisibles par l'homme lorsqu'ils sont consultés directement dans un navigateur. Le principal cas d'utilisation est que lorsqu'un utilisateur clique accidentellement sur le lien du flux RSS d'un site, au lieu de coller ce lien dans son lecteur RSS, il reçoit une réponse HTML mise en forme qu'il peut lire, plutôt que le code XML brut lui-même.
Il existe deux solutions pour ce cas d'utilisation. La méthode HTML "standard" consiste à ajouter <link rel="alternate" type="application/rss+xml"> à un
site (basé sur HTML), plutôt qu'à ajouter un <a
href="something.xml"> explicite (visible par l'utilisateur) sur lequel les utilisateurs pourraient cliquer accidentellement. Cette solution permet aux lecteurs RSS de trouver le flux si un utilisateur colle uniquement l'URL du site Web, mais elle permet également aux utilisateurs humains de voir le contenu HTML normal sans être déroutés par un lien vers une ressource XML. Cela suit également le paradigme Web normal selon lequel HTML est destiné aux humains et XML aux machines. Bien sûr, cela ne résout pas le cas où un utilisateur "dispose" simplement d'un lien RSS provenant d'un autre endroit et le colle dans son navigateur Web (plutôt que dans son lecteur RSS).
Lorsque cette solution n'est pas souhaitée, le polyfill offre une autre solution. Comme mentionné
précédemment, le flux XML RSS/Atom peut être augmenté d'une ligne, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>,
qui maintiendra le comportement existant de la transformation basée sur XSLT en HTML.
Cela ne devrait pas affecter la capacité du lecteur RSS à continuer d'analyser le code XML, car
le <script> est un enfant direct de l'élément racine.
Sortie d'API pour les appareils intégrés
Certains appareils intégrés commerciaux mesurent ou génèrent des données XML pour être utilisées par les utilisateurs sur le réseau local. Certains de ces appareils génèrent un seul flux de données XML qui utilise XSLT pour le transformer en un format HTML lisible par l'homme. Cela permet d'afficher directement l'API dans un navigateur sans avoir besoin de code supplémentaire sur l'appareil ou dans le navigateur.
Comme il s'agit d'un cas d'utilisation très spécifique à l'application, la forme de la solution peut varier. Pour les applications dont le code source de l'appareil intégré peut être mis à jour, n'importe laquelle des options décrites précédemment (JSON, Polyfill) peut fonctionner. Cependant, de nombreux appareils de ce type sont difficiles, voire impossibles à mettre à jour, pour diverses raisons. Dans ce cas, l'
extension
est probablement la meilleure option, car elle permet aux navigateurs clients de continuer à lire
les données exactement de la même manière, sans modifier l'appareil.
Création de modèles différée pour les sites Web
Les développeurs Web utilisent parfois XSLT côté client pour appliquer un balisage de présentation à un balisage sémantique, fonctionnant comme un langage de création de modèles différée distinct de l'écosystème JavaScript.
Il existe deux solutions à ce problème plus général. Pour un site existant créé de cette manière, la solution la plus simple consiste probablement à ajouter le polyfill pour maintenir les fonctionnalités existantes. Vous pouvez également effectuer la transformation XSLT côté serveur et diffuser le code HTML résultant au client, plutôt que le code XML brut. La solution à plus long terme pour ces propriétés consiste à migrer vers un framework plus moderne basé sur JavaScript ou JSON.
Si vous rencontrez un problème spécifique dans Chrome lié à cet abandon de XSLT, signalez un bug ici.
Détecter l'utilisation de XSLT
En général, les fonctionnalités obsolètes telles que XSLT peuvent être détectées dans votre codebase de plusieurs manières. Cette section en présente deux.
API Reporting
L'API Reporting est un mécanisme de création de rapports générique permettant aux applications Web de générer des rapports sur diverses fonctionnalités et conditions de la plate-forme, y compris les abandons de fonctionnalités. Pour la configurer afin de générer des rapports sur l'abandon de XSLT, vous pouvez utiliser un extrait de code comme celui-ci :
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
Découvrez ce code en action sur CodePen.
Rapport sur les anciennes technologies pour les entreprises
Pour les administrateurs d'une entreprise, le rapport sur les anciennes technologies peut être utilisé pour collecter automatiquement l'utilisation des fonctionnalités obsolètes et les signaler de manière conviviale. Pour en savoir plus sur l'activation de cette fonctionnalité, consultez cet article de l'assistance Google.