Polyfill de XSLT: la extensión, el arreglo de una línea y la fecha de Edge

Foto de Marco Orta | 12 min de lectura
Portada tipográfica sobre una rejilla verde oscura: XSLT Polyfill en letras grandes y un diff que cambia el XSLTProcessor nativo por xslt-polyfill.min.js para Chrome 158 y Edge 159
Tabla de Contenidos

    La barra roja «Este sitio usa XSLT» termina con una sugerencia: «Es posible que puedas instalar una extensión del navegador para seguir viéndolo». Esa extensión es XSLT Polyfill: libxslt compilado a WebAssembly, que sigue corriendo en tu navegador cuando Chrome quite el suyo. Si el sitio es tuyo, el mismo polyfill cabe en una línea <script> dentro del XML. Probé esa línea en un sitemap con estilo y en un feed RSS, en Chrome con XSLT apagado, y los dos se vieron exactamente igual que antes y sin la barra. Y una cosa más que la gente está buscando: Microsoft Edge no quita XSLT junto con Chrome. Lo quita una versión después, en Edge 159, la semana del 10 de diciembre de 2026.

    Esto sigue a Chrome quita XSLT: qué se rompe, que trae el calendario completo, qué significa la barra y el código de CFDI que sí truena. Aquí solo van los arreglos a los que apunta la barra.

    Cuál arreglo te toca

    EresQué vesArreglo
    Visitante en ChromeLa barra roja en una página ajenaNada hasta el 17 de noviembre. Después, la extensión XSLT Polyfill, o avisar al dueño del sitio
    Visitante en EdgeLa misma barraLa misma extensión, instalada desde la Chrome Web Store. Tu fecha límite es diciembre
    Sistemas de una empresa con una app que no puede cambiarLa barra en una intranet, el panel de un equipo o la app de un proveedorLa política XSLTEnabled, en Chrome y en Edge, hasta agosto de 2027
    Dueño de un sitemap o un feed con estiloLa barra en tu propio .xmlEl polyfill de una línea, o quitar la hoja de estilo
    Dueño de JavaScript que llama a XSLTProcessorAvisos en la consola, y ReferenceError desde Chrome 158Cargar el polyfill antes de tu código, o mover la transformación al servidor

    Las fechas, Chrome y Edge

    Las de Chrome salen de Chromium Dash y del anuncio de Chrome. Las de Edge, del calendario de versiones de Edge y del mensaje MC1509789 de Microsoft 365, publicado el 15 de octubre de 2026. Todas cotejadas el 23 de octubre.

    HitoChromeEdge
    Barra roja en páginas con XSLTChrome 154, 22-sep-2026Ya se ve (Edge 154 salió el 24-sep)
    Beta de la versión que lo quitaChrome 158, 28-octEdge 159, semana del 17-nov
    XSLT apagado en estableChrome 158, 17-nov-2026Edge 159, semana del 10-dic-2026
    Fin de la política empresarial y del Origin TrialChrome 176, 17-ago-2027Edge 176, «verano de 2027»

    Microsoft lo dice así: en Edge 159, el XSLT nativo del navegador «estará apagado por defecto en estable», y da como motivo reducir la superficie de ataque. Edge 158 sale la semana del 19 de noviembre todavía con XSLT. Son unas tres semanas más para quien usa Edge, nada más: todo usuario de Edge que hoy ve la barra se queda sin XSLT antes de que acabe el año.

    Si eres visitante: la extensión XSLT Polyfill

    El enlace «instalar una extensión del navegador» de la barra abre una búsqueda de «XSLT Polyfill» en la Chrome Web Store. El resultado al que enlaza el propio anuncio de Chrome es este. El 23 de octubre la ficha decía:

    • Versión 1.0.25, actualizada el 20 de octubre de 2026, 514 KiB.
    • 100 000 usuarios, 4.2 estrellas con 10 calificaciones.
    • Un correo de contacto que coincide con el autor del polyfill (mfreed7 en GitHub y npm).
    • La declaración de que no recopila datos del usuario y de que todo se procesa en tu equipo.

    Lo que hace, según su descripción: cuando una página es XML crudo con una instrucción de XSLT, ejecuta la hoja con el polyfill y la página se ve como antes. También pone un XSLTProcessor de reemplazo, para que el JavaScript que usaba XSLT siga funcionando. En páginas sin XSLT, o en un navegador que todavía trae XSLT nativo, no hace nada. Eso quiere decir que instalarla hoy no cambia nada a la vista: empieza a trabajar el día que tu navegador quite XSLT.

    Antes de instalarla, aplica la regla de siempre con las extensiones: una que reescribe páginas necesita acceso amplio a ellas. Revisa los permisos que te muestra Chrome, y quédate con la ficha que enlaza el anuncio de Chrome antes que con las parecidas que salgan en la misma búsqueda.

    Firefox todavía trae XSLT y no tiene fecha para quitarlo, así que ahí no necesitas nada hoy. En addons.mozilla.org hay otro complemento con el mismo nombre, de otro autor (zcorpan).

    Edge: la misma barra, una versión después

    Edge está hecho sobre Chromium, así que heredó la barra. En septiembre un usuario de Edge preguntó en Microsoft Q&A por qué el portal web de Escritorio Remoto le mostraba «This site uses XSLT…». La respuesta fue la misma que para Chrome: el arreglo le toca al dueño del sitio, y la política solo compra tiempo.

    En la tienda de complementos de Edge no hay ficha de XSLT Polyfill (la busqué el 23 de octubre). Pero Edge instala extensiones de la Chrome Web Store: abre la ficha en Edge, acepta el aviso «Permitir extensiones de otras tiendas» y agrégala con el botón de la ficha.

    Para sistemas. Edge tiene su propia política XSLTEnabled, documentada en Microsoft Learn desde Edge 147 en Windows y macOS (no en Android ni iOS). Activada, mantiene XSLT disponible sin importar lo que traiga el navegador por defecto. Microsoft planea quitarla en Edge 176:

    Directiva de grupo: Plantillas administrativas > Microsoft Edge > Control the availability of the XSLT feature
    Registro:           HKLM\SOFTWARE\Policies\Microsoft\Edge   XSLTEnabled   REG_DWORD   0x00000001
    macOS:              XSLTEnabled = <true/>
    

    La lista que Microsoft da a los administradores vale aunque solo uses Chrome: corre Lighthouse en modo Navegación con la categoría Best Practices en cada app interna (con «Clear storage» apagado en las que piden inicio de sesión) y busca avisos de XSLT obsoleto en el reporte, en el panel Issues y en la consola.

    Si el sitio es tuyo: el polyfill de una línea

    El mismo polyfill que usa la extensión puede ir dentro de tu XML, y así tus visitantes no necesitan ninguna extensión. Está en npm como xslt-polyfill (1.0.33 del 21 de octubre de 2026, licencia BSD-3-Clause). Las instrucciones del README: agregar un elemento <script> en el espacio de nombres de XHTML como hijo del elemento raíz, antes del contenido.

    <?xml version="1.0" encoding="UTF-8"?>
    <?xml-stylesheet type="text/xsl" href="/sitemap.xsl"?>
    <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
      <script src="/xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>
      <url><loc>https://example.com/a/</loc></url>
      <url><loc>https://example.com/b/</loc></url>
    </urlset>
    

    Lo que probé

    Serví desde un servidor local un sitemap con una hoja XSL pequeña (un <h1> y una tabla de enlaces). Lo abrí en Chrome 155 con --enable-features=XSLT y con --disable-features=XSLT, que es como se va a comportar Chrome 158, y saqué el DOM de cada resultado:

    SitemapXSLT encendido (hoy)XSLT apagado (Chrome 158)
    Solo la hoja de estiloLa tabla, con la barra rojaEl visor de XML crudo de Chrome
    Hoja + la línea del polyfillLa tabla, sin barraLa tabla, sin barra: el mismo <h1> y las mismas 2 filas

    Salieron tres detalles:

    • La línea también quita la barra hoy. Mientras exista el XSLT nativo, el polyfill no se instala. Además, Chromium toma un script en esa posición como señal de que el polyfill está desplegado y no muestra la barra (desde Chrome 155). La misma línea arregla noviembre y quita el aviso desde ya.
    • No tiene que ser hija directa de la raíz. En un feed RSS la puse dentro de <channel>, un nivel más abajo, y el resultado fue el mismo en los dos modos.
    • Funciona desde un CDN. Con el src apuntando a https://cdn.jsdelivr.net/npm/xslt-polyfill@1.0.33/xslt-polyfill.min.js también se vio la tabla. Si no quieres depender de un tercero, sírvelo tú. En los dos casos, fija la versión.

    El costo es el peso: xslt-polyfill.min.js mide 1.46 MB, con el WebAssembly adentro. Solo lo descarga quien abre tu sitemap o tu feed en un navegador, y después queda en caché.

    En Astro

    @astrojs/rss acepta XML crudo en customData y lo mete dentro de <channel>. Lo comprobé con la versión 4.0.19. Escribe el elemento autocerrado (<script ... />), que en XML es válido, y comprobé que así también carga el polyfill:

    // src/pages/rss.xml.js
    import rss from '@astrojs/rss';
    
    export async function GET(context) {
      return rss({
        title: 'Mi blog',
        description: '…',
        site: context.site,
        stylesheet: '/rss.xsl',
        customData:
          '<script src="/xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>',
        items: [],
      });
    }
    

    Copia node_modules/xslt-polyfill/xslt-polyfill.min.js a public/, o usa la URL del CDN. @astrojs/sitemap no tiene opción para insertar un elemento. Si ahí usas xslURL, lo sencillo es quitarlo o postprocesar el archivo generado.

    En WordPress

    El núcleo, Yoast y Rank Math tienen filtros para cambiar o quitar la URL de la hoja de estilo, pero ningún gancho limpio para meter un elemento dentro de <urlset>. Mientras WordPress no publique su propio arreglo (ticket #65593, versión 7.2), lo práctico es lo del artículo anterior: quitar la hoja de estilo, o servir aparte una versión en HTML.

    Para JavaScript que llama a XSLTProcessor

    Carga el polyfill como un script normal antes de tu código. new XSLTProcessor(), importStylesheet() y transformToFragment() siguen funcionando cuando el navegador ya no tiene la versión nativa. Para probarlo en el Chrome de hoy, pon window.xsltUsePolyfillAlways = true antes de cargar el script.

    Los límites

    • Solo XSLT 1.0. El README lo describe como un polyfill de XSLT 1.0 «más o menos como venía en Chrome», y para algo más remite a SaxonJS.
    • xsl:include, xsl:import y document() se cargan con fetch(). Eso quiere decir que aplica CORS, que el procesador nativo se saltaba. Una hoja que incluye archivos de otro dominio va a fallar. Como fetch() es asíncrono y los métodos de XSLTProcessor son síncronos, esos métodos fallan cuando la hoja tiene includes. Con una hoja sencilla de sitemap en tu propio dominio no te pasa. Con una compleja (como la hoja del SAT para el CFDI, con 33 includes), primero aplánala en un solo archivo. El artículo anterior trae ese caso comprobado contra un sello real.
    • Los rastreadores. No encontré ninguna declaración de Google sobre un <script> dentro de un sitemap. Lo que sí se puede comprobar es el esquema del propio protocolo: sitemap.xsd permite elementos de otros espacios de nombres al inicio de <urlset>, antes del primer <url>. La línea va justo ahí, así que cabe en la estructura del protocolo. Un validador estricto puede quejarse de todos modos, porque el esquema le pide validar esos elementos. Si nadie abre tu sitemap en un navegador, quitar la hoja de estilo es más sencillo que agregar el polyfill.

    Cómo comprobar que funcionó

    # 1. La línea está en lo que de verdad sirves
    curl -s https://tusitio.com/sitemap.xml | head -c 600 | grep -o '<script[^>]*xslt-polyfill[^>]*>'
    
    # 2. Se ve con XSLT apagado, como en Chrome 158
    chrome --headless=new --disable-features=XSLT --virtual-time-budget=8000 \
      --dump-dom https://tusitio.com/sitemap.xml | grep -c '<tr'
    # > 0 → ahí está la tabla. 0 → estás viendo el visor de XML crudo
    

    --virtual-time-budget importa: el polyfill carga de forma asíncrona y, sin él, --dump-dom puede capturar la página antes de la transformación. En una ventana normal, chrome://flags/#xslt en Disabled da el mismo resultado.

    . Lo probé en Chrome con XSLT apagado en un sitemap y en un feed RSS, con la línea dentro de channel, y los dos se vieron como antes. El archivo pesa unos 1.46 MB y está en npm como xslt-polyfill."}},{"@type":"Question","name":"¿El polyfill quita la barra «Este sitio usa XSLT»?","acceptedAnswer":{"@type":"Answer","text":"Sí. Chromium no muestra la barra cuando el XML trae un script de XHTML a dos niveles o menos del elemento raíz, porque lo toma como señal de que el polyfill está desplegado. En mi prueba con Chrome 155, el sitemap con la línea del polyfill no mostró la barra con XSLT nativo encendido, y con XSLT apagado se vio la misma tabla."}},{"@type":"Question","name":"¿Es válido un elemento script dentro de un sitemap?","acceptedAnswer":{"@type":"Answer","text":"El esquema de sitemaps.org permite elementos de otros espacios de nombres al inicio de urlset, antes del primer url, que es donde va la línea del polyfill. Google no ha publicado nada específico al respecto. Un validador estricto puede quejarse, porque el esquema le pide validar esos elementos. Si nadie abre tu sitemap en un navegador, es más sencillo quitar la hoja XSL."}},{"@type":"Question","name":"¿El polyfill de XSLT soporta xsl:include?","acceptedAnswer":{"@type":"Answer","text":"Carga xsl:include, xsl:import y document() con fetch, así que esas peticiones quedan sujetas a CORS, a diferencia del procesador nativo. Como fetch es asíncrono, los métodos síncronos de XSLTProcessor fallan cuando la hoja tiene includes. Aplana la hoja en un solo archivo para evitar los dos problemas."}}]}

    Preguntas frecuentes

    ¿Qué es la extensión XSLT Polyfill que sugiere la barra de Chrome?

    Es una extensión del navegador que ejecuta XSLT con libxslt compilado a WebAssembly, para que las páginas XML con estilo XSLT se sigan viendo cuando el navegador quite su XSLT nativo. También pone un XSLTProcessor de reemplazo para JavaScript. No hace nada en páginas sin XSLT ni mientras el navegador todavía trae XSLT nativo. La ficha de la Chrome Web Store que enlaza el anuncio de Chrome mostraba el 23 de octubre de 2026 la versión 1.0.25, 100 000 usuarios y la declaración de que todo se procesa en tu equipo sin recopilar datos.

    ¿Cuándo quita Microsoft Edge el XSLT?

    En Edge 159, cuya versión estable está planeada para la semana del 10 de diciembre de 2026, según el calendario de versiones de Microsoft y el mensaje MC1509789. Edge 158, la semana del 19 de noviembre, todavía trae XSLT. Chrome lo quita antes, en Chrome 158, el 17 de noviembre de 2026. La política temporal XSLTEnabled de Edge desaparece en Edge 176, en el verano de 2027.

    ¿Puedo instalar la extensión XSLT Polyfill en Edge?

    Al 23 de octubre de 2026 no hay ficha de XSLT Polyfill en la tienda de complementos de Edge, pero Edge instala extensiones de la Chrome Web Store. Abre la ficha de la Chrome Web Store en Edge, acepta Permitir extensiones de otras tiendas y agrégala.

    ¿Cómo agrego el polyfill de XSLT a un sitemap o a un feed RSS?

    Agrega un elemento script en el espacio de nombres de XHTML al inicio del XML, como hijo del elemento raíz: <script src="/xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>. Lo probé en Chrome con XSLT apagado en un sitemap y en un feed RSS, con la línea dentro de channel, y los dos se vieron como antes. El archivo pesa unos 1.46 MB y está en npm como xslt-polyfill.

    ¿El polyfill quita la barra «Este sitio usa XSLT»?

    Sí. Chromium no muestra la barra cuando el XML trae un script de XHTML a dos niveles o menos del elemento raíz, porque lo toma como señal de que el polyfill está desplegado. En mi prueba con Chrome 155, el sitemap con la línea del polyfill no mostró la barra con XSLT nativo encendido, y con XSLT apagado se vio la misma tabla.

    ¿Es válido un elemento script dentro de un sitemap?

    El esquema de sitemaps.org permite elementos de otros espacios de nombres al inicio de urlset, antes del primer url, que es donde va la línea del polyfill. Google no ha publicado nada específico al respecto. Un validador estricto puede quejarse, porque el esquema le pide validar esos elementos. Si nadie abre tu sitemap en un navegador, es más sencillo quitar la hoja XSL.

    ¿El polyfill de XSLT soporta xsl:include?

    Carga xsl:include, xsl:import y document() con fetch, así que esas peticiones quedan sujetas a CORS, a diferencia del procesador nativo. Como fetch es asíncrono, los métodos síncronos de XSLTProcessor fallan cuando la hoja tiene includes. Aplana la hoja en un solo archivo para evitar los dos problemas.

    ¿Te sirvió? Compártelo

    ¿Te sirvió? Recibe la próxima por correo

    Una vez por semana: qué se rompe al actualizar, IA para desarrolladores y lo que estoy construyendo, con fuentes. Sin spam.

    Al suscribirte aceptas nuestro aviso de privacidad.

    Buscar

    Etiquetas

    PHP IA Laravel Migración JavaScript Tutorial Seguridad Desarrollo Web Upgrade Buenas Prácticas SEO Agentes MCP OpenAI Backend