Publicado el 29 de octubre de 2025
Chrome tiene la intención de dar de baja y quitar XSLT del navegador. En este documento, se detalla cómo puedes migrar tu código antes de la eliminación a fines de 2026.
Chromium dio de baja oficialmente XSLT, incluida la XSLTProcessor y la instrucción de procesamiento XSLT. Tenemos la intención de quitar la compatibilidad con la versión 158 (17 de noviembre de 2026). Los Firefox de WebKit y WebKit también indicaron planes para quitar XSLT de sus motores de navegadores. En este documento, se proporciona algo de historia y contexto, se explica cómo quitaremos XSLT para que Chrome sea más seguro y se proporciona una ruta de migración antes de que se quiten estas funciones del navegador. Para obtener las actualizaciones más recientes, consulta también la entrada Estado de la plataforma de Chrome.
¿Qué se quitará?
Existen dos APIs en el navegador que implementan XSLT, y ambas se quitarán:
- La
XSLTProcessor
XSLTProcessor (por ejemplo,
new XSLTProcessor()). - La instrucción de procesamiento
XSLT
(por ejemplo,
<?xml-stylesheet type="text/xsl" ... ?>).
Cronograma de Chrome
Chrome tiene el siguiente plan:
- Chrome 142 (28 de octubre de 2025): Se agregaron mensajes de advertencia temprana a la consola de Chrome.
- Chrome 143 (2 de diciembre de 2025): Baja oficial de la API: Los mensajes de advertencia de baja comienzan a mostrarse en la consola y en Lighthouse.
- Chrome 145 (2 de diciembre de 2025 Canary): Las versiones Canary, Dev y Beta comienzan a inhabilitar XSLT de forma predeterminada, como advertencia temprana.
- Chrome 146 (10 de marzo de 2026): La política empresarial (EP) se lanza para realizar pruebas. Esto permite que las empresas prueben la inhabilitación de XSLT de forma anticipada y también les permitirá seguir usando funciones después de la fecha de eliminación.
- Chrome 152 (25 de agosto de 2026): La prueba de origen (OT) se lanza para realizar pruebas. Esto permite que los sitios sigan usando funciones después de la fecha de eliminación.
- Chrome 158 (17 de noviembre de 2026): XSLT deja de funcionar en las versiones estables para todos los usuarios, excepto los participantes de la prueba de origen y la política empresarial.
- Chrome 176 (17 de agosto de 2027): Dejan de funcionar la prueba de origen y la política empresarial. XSLT está inhabilitado para todos los usuarios.
¿Qué es XSLT?
XSLT, o transformaciones de lenguaje de hojas de estilo extensibles, es un lenguaje que se usa para transformar documentos XML, por lo general, en otros formatos, como HTML. Usa un archivo de hoja de estilo XSLT para definir las reglas de esta conversión y un archivo XML que contiene los datos que se usan como entrada.
En los navegadores, cuando se recibe un archivo XML que se vincula a una hoja de estilo XSLT, el navegador usa las reglas de esa hoja de estilo para reorganizar, dar formato y convertir los datos XML sin procesar en una página estructurada (a menudo HTML) que se puede renderizar para el usuario.
Por ejemplo, una hoja de estilo XSLT podría tomar la siguiente entrada XML:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
y esta hoja de estilo 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>
y procesarlos en este HTML para que el navegador lo muestre: HTML
<body>
<p>Message: Hello World.</p>
</body>
Además de la instrucción de procesamiento XSL que se muestra en el ejemplo anterior, también está la XSLTProcessor API de JavaScript, que se puede usar para procesar documentos XML locales con hojas de estilo XSLT locales.
Historial de XSLT
El World Wide Web Consortium (W3C) recomendó XSLT el 16 de noviembre de 1999 como un lenguaje para transformar documentos XML en otros formatos, por lo general, HTML para mostrar en navegadores web. Antes de la recomendación oficial 1.0, Microsoft tomó una iniciativa temprana y envió una implementación de propiedad basada en un borrador de trabajo de W3C en Internet Explorer 5.0, lanzado en marzo de 1999. Siguiendo el estándar oficial, Mozilla implementó la compatibilidad nativa con XSLT 1.0 en Netscape 6 a fines de 2000. Otros navegadores importantes, incluidos Safari, Opera y, más tarde, Chrome, también incorporaron procesadores XSLT 1.0 nativos, lo que convirtió las transformaciones de XML a HTML del lado del cliente en una tecnología web viable a principios de la década de 2000.
El lenguaje XSLT en sí siguió evolucionando con el lanzamiento de XSLT 2.0 en 2007 y XSLT 3.0 en 2017, que introdujeron funciones potentes como expresiones regulares, tipos de datos mejorados y la capacidad de procesar JSON. Sin embargo, la compatibilidad con el navegador se estancó. Actualmente, todos los motores de navegadores web principales solo proporcionan compatibilidad nativa con el XSLT 1.0 original de 1999. Esta falta de avance, junto con el aumento del uso de JSON como formato de cable y las bibliotecas y los frameworks de JavaScript (como jQuery, React y Vue.js) que ofrecen una manipulación y plantillas del DOM más flexibles y potentes, provocó una disminución significativa en el uso de XSLT del lado del cliente. Su función en el navegador web se sustituyó en gran medida por estas tecnologías basadas en JavaScript.
¿Por qué se debe quitar XSLT?
La inclusión continua de XSLT 1.0 en los navegadores web presenta un riesgo de seguridad significativo e innecesario. Las bibliotecas subyacentes que procesan estas transformaciones, como libxslt (que usan los navegadores Chromium), son bases de código C/C++ complejas y antiguas. Este tipo de código es notoriamente susceptible a vulnerabilidades de seguridad de la memoria, como los desbordamientos del búfer, que pueden provocar la ejecución de código arbitrario. Por ejemplo, las auditorías de seguridad y los rastreadores de errores identificaron repetidamente vulnerabilidades graves en estos analizadores (p.ej., CVE-2025-7425 y CVE-2022-22834, ambos en libxslt). Dado que XSLT del lado del cliente ahora es una función de nicho que se usa con poca frecuencia, estas bibliotecas reciben mucha menos atención en cuanto a mantenimiento y seguridad que los motores principales de JavaScript, pero representan una superficie de ataque directa y potente para procesar contenido web no confiable. De hecho, XSLT es la fuente de numerosos exploits de seguridad recientes y mediáticos que siguen poniendo en riesgo a los usuarios del navegador. Los riesgos de seguridad de mantener esta funcionalidad heredada y frágil superan con creces su utilidad moderna limitada.
Además, el propósito original de XSLT del lado del cliente (transformar datos en HTML renderizable) se reemplazó por APIs de JavaScript más seguras, ergonómicas y mejor mantenidas. El desarrollo web moderno se basa en elementos como la API de Fetch para recuperar datos (por lo general, JSON) y la API de DOMParser para analizar de forma segura cadenas XML o HTML en una estructura DOM dentro del sandbox seguro de JavaScript del navegador. Luego, frameworks como React, Vue y Svelte administran la renderización de estos datos de manera eficiente y segura. Esta cadena de herramientas moderna se desarrolla de forma activa, se beneficia de la gran inversión en seguridad en los motores de JavaScript y es lo que usan prácticamente todos los desarrolladores web en la actualidad. De hecho, solo alrededor del 0.02% de las cargas de páginas web actuales usan XSLT, y menos del 0.001% usa instrucciones de procesamiento XSLT.
Esta no es una acción exclusiva de Chrome o Chromium: los otros dos motores de navegadores principales también admiten la eliminación de XSLT de la plataforma web: WebKit y Gecko.
Por estos motivos, dar de baja y quitar XSLT reduce la superficie de ataque del navegador para todos los usuarios, simplifica la plataforma web y permite que los recursos de ingeniería se centren en proteger las tecnologías que realmente impulsan la Web moderna, sin pérdida práctica de capacidad para los desarrolladores.
Mejora de la seguridad del análisis de XML
Al igual que los graves problemas de seguridad en libxslt, graves problemas de seguridad se informaron recientemente en libxml2, que se usa en Chromium para analizar, serializar y probar el formato correcto de XML. Para abordar futuros problemas de seguridad con el análisis de XML en Chromium, planeamos eliminar el uso de libxml2 y reemplazar el análisis de XML por una biblioteca de análisis de XML con seguridad de memoria escrita en Rust. Es importante destacar que no quitaremos XML del navegador; solo se considera quitar XSLT. Tenemos la intención de garantizar que el reemplazo de libxml2 sea completamente transparente para los desarrolladores web.
No se quitará XML + CSS
Es importante distinguir la baja de XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) de la
<?xml-stylesheet ... ?> instrucción de procesamiento en sí, que sigue siendo compatible
cuando se usa con CSS. Aún puedes usar la instrucción de procesamiento con
type="text/css" para aplicar reglas de diseño y diseño estándar a tus datos sin procesar,
al igual que con HTML. Por ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
Cómo realizar la migración
Existen algunas rutas alternativas para la migración.
JSON
Para los sitios que se compilan por completo en XML y XSL, no hay una forma única de realizar la transición. Las opciones de migración incluyen mover la canalización de procesamiento XSLT al servidor y enviar el HTML renderizado al cliente, o migrar los extremos de la API de XML del servidor a JSON y realizar la renderización del cliente con JavaScript para transformar JSON en HTML DOM y CSS.
XSLT del cliente en JavaScript
Existen algunas bibliotecas XSLT del cliente (basadas en JavaScript) disponibles, pero la más grande es producida por Saxonica (consulta la documentación completa de Saxonica). La implementación va mucho más allá de la implementación de XSLT 1.0 en navegadores web, ya que implementa compatibilidad total con el estándar v3.0 más reciente y, finalmente, el estándar v4.0 en curso.
Polyfill
Existe un polyfill que intenta permitir que el código existente, que depende de las implementaciones de XSLT 1.0 de los navegadores web, siga funcionando sin usar las funciones XSLT nativas del navegador. El polyfill se encuentra en GitHub.
El polyfill contiene un reemplazo funcional basado en WASM para la clase XSLTProcessor, por lo que el código JavaScript existente puede seguir funcionando tal como está:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
El polyfill también proporciona una función de utilidad automática para reemplazar fácilmente los documentos XML que usan instrucciones de procesamiento XSLT:
Para un archivo demo.xml original como este:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Se puede agregar una línea para invocar el polyfill y transformar el documento con la hoja de estilo XSLT a la que se hace referencia:
<?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...
En este caso, el nuevo elemento <script> carga el polyfill, que detecta el
tipo de documento XML y la instrucción de procesamiento XSLT, y lo carga de forma transparente
, reemplazando el documento.
Extensión
También hay una extensión de Chrome que se puede agregar a los navegadores compatibles, que aplicará el mismo polyfill XSLT a todas las páginas XML sin procesar que contengan instrucciones de procesamiento XSLT o llamadas a XSLTProcessor. Esto se puede usar para aplicaciones en las que no se puede cambiar el XML o XSLT fuente para mantener la funcionalidad.
En particular, cuando XSLT está inhabilitado, Chrome ahora muestra un banner de advertencia que se vincula directamente a una página de búsqueda de extensiones para ayudar a los usuarios a encontrar una extensión:
Casos de uso específicos
En el debate sobre los estándares de HTML, se identificaron varios casos de uso concretos. En esta sección, se habla específicamente de cada uno de ellos para recomendar rutas de avance para los desarrolladores que publican recursos XML que usan XSLT en la actualidad.
Feeds RSS y Atom
En muchos feeds RSS o Atom existentes, se usa XSLT para que los feeds XML sin procesar sean legibles para las personas cuando se ven directamente en un navegador. El caso de uso principal es que, cuando un usuario hace clic accidentalmente en el vínculo del feed RSS de un sitio, en lugar de pegar ese vínculo en su lector de RSS, obtiene una respuesta HTML con formato que puede leer, en lugar del XML sin procesar.
Existen dos rutas de avance para este caso de uso. La forma "estándar" de HTML de hacer
esto es agregar <link rel="alternate" type="application/rss+xml"> a un
sitio (basado en HTML), en lugar de agregar un <a
href="something.xml"> explícito (visible para el usuario) en el que los usuarios podrían hacer clic accidentalmente. Esta solución permite que los lectores de RSS encuentren el feed si un usuario pega solo la URL del sitio web, pero también permite que los usuarios humanos vean el contenido HTML normal sin confundirse con un vínculo a un recurso XML. Esto también sigue el paradigma web normal de que HTML es para humanos y XML es para máquinas. Por supuesto, esto no resuelve el caso en el que un usuario simplemente "tiene" un vínculo RSS de algún lugar y lo pega en su navegador web (en lugar de en su lector de RSS).
Cuando no se desea esa solución, el polyfill ofrece otra ruta. Como se mencionó
anteriormente, el feed XML de RSS/Atom se puede aumentar con una línea, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>,
que mantendrá el comportamiento existente de la transformación basada en XSLT a HTML.
Eso no debería afectar la capacidad del lector de RSS para seguir analizando el XML, ya que
el <script> es un elemento secundario directo del elemento raíz.
Salida de la API para dispositivos incorporados
Algunos dispositivos incorporados comerciales miden o generan datos XML para que los usen los usuarios en la red local. Algunos de estos dispositivos lo hacen generando un solo feed de datos XML que usa XSLT para transformarlo en un formato HTML legible para las personas. Eso permite que la API se vea directamente en un navegador sin necesidad de código adicional en el dispositivo o en el navegador.
Dado que este es un caso de uso muy específico de la aplicación, la forma de la solución puede variar. Para las aplicaciones en las que se puede actualizar el código fuente del dispositivo incorporado, cualquiera de las opciones descritas anteriormente (JSON, Polyfill) podría funcionar. Sin embargo, en particular, muchos de estos dispositivos son difíciles o imposibles de actualizar por varios motivos. En ese caso, la
extensión
es probablemente la mejor opción, ya que permite que los navegadores cliente sigan leyendo
los datos exactamente de la misma manera, sin modificar el dispositivo.
Plantillas diferidas para sitios web
A veces, los desarrolladores web usan XSLT del lado del cliente para aplicar el lenguaje de marcado de presentación al lenguaje de marcado semántico, que funciona como un lenguaje de plantillas diferido que está separado del ecosistema de JavaScript.
Existen dos soluciones para este problema más general. Para un sitio existente compilado de esta manera, la solución más sencilla es agregar el polyfill para mantener la funcionalidad existente. O quizás realizar la transformación XSLT en el servidor y entregar el HTML resultante al cliente, en lugar del XML sin procesar. La solución a más largo plazo para estas propiedades sería migrar a un framework más moderno basado en JavaScript o JSON.
Si encuentras un problema específico en Chrome relacionado con esta baja de XSLT, informa un error aquí.
Cómo detectar el uso de XSLT
En general, las funciones obsoletas, como XSLT, se pueden detectar en tu base de código de varias maneras. En esta sección, se describen dos de ellas.
La API de Reporting
La API de Reporting es un mecanismo de informes genérico para que las aplicaciones web informen sobre varias funciones y condiciones de la plataforma, incluidas las bajas de funciones. Para configurarlo para que informe sobre la baja de XSLT, se puede usar un fragmento de código como este:
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();
Mira este código en acción en CodePen.
El informe de tecnología heredada empresarial
Para los administradores de una empresa, el informe de tecnología heredada se puede usar para recopilar automáticamente el uso de funciones obsoletas y volver a informarlas de una manera fácil de usar. Consulta este artículo de la Ayuda de Google para obtener más información sobre cómo habilitar esta función.