Chrome y Edge están eliminando XSLT: qué se rompe y qué no

Artículo original ↗ Discusión en Hacker News ↗

Chrome y Edge están descontinuando el soporte integrado de XSLT, lo que genera preocupación por roturas en sitios basados en XML, feeds RSS/Atom con estilo y flujos de trabajo de nicho que dependen de transformaciones del lado del cliente. Quienes apoyan la eliminación argumentan que XSLT se usa poco, es complejo de mantener y supone una superficie de seguridad y ataque no trivial, especialmente con bibliotecas XML envejecidas; otros lamentan la pérdida de una potente herramienta declarativa de plantillas y un símbolo de la visión XML/XHTML abandonada para la web. Entre las alternativas se mencionan las transformaciones del lado del servidor, motores XSLT basados en JavaScript o WebAssembly, o un estilo CSS más simple, aunque muchos consideran que no existe un reemplazo equivalente real.

Alcance del cambio

  • Chrome está descontinuando y eliminando XSLT integrado; se espera que Edge, como bifurcación de Chromium, lo siga.
  • Firefox por ahora todavía funciona, pero registra advertencias y también tiene una “intención de retirar” XSLT.
  • Efecto neto: XSLT en el navegador desaparece; XSLT del lado del servidor no se ve afectado.

Razones dadas para la eliminación

  • Función heredada, poco usada, con una superficie de ataque grande y compleja.
  • Las bibliotecas XML subyacentes son antiguas, están poco mantenidas y tienen un historial de vulnerabilidades.
  • Mantener este código para miles de millones de usuarios se considera costoso.
  • Algunos ven en los LLM una forma de abaratar el mantenimiento; otros argumentan que también reducen el coste de encontrar exploits y no eliminan los costes de seguridad/mantenimiento.

Escepticismo y críticas

  • Algunos lo ven como comportamiento de monocultivo de navegador: los proveedores “simplemente retiran cosas porque no se molestan”.
  • Unos pocos lo enmarcan como un patrón similar al declive de Flash: crear una narrativa de seguridad para justificar la eliminación de tecnología incómoda.
  • Otros responden que casi nadie usa ni mantiene XSLT ya y que es irrazonable esperar soporte continuo.

Impacto y roturas

  • Las interfaces basadas en XML+XSLT (p. ej., algunos informes de IIS, lectores TEI/XML, feeds RSS/Atom con estilo, blogs basados en XSLT) se romperán o degradarán en navegadores basados en Chromium.
  • Chrome ya muestra una advertencia destacada al usar XSLT.
  • Se señala que los sitios gubernamentales y regulatorios que usan XSLT están en riesgo (incidencias enlazadas).

Alternativas y caminos de migración

  • Hacer la transformación XSLT en el servidor y servir HTML plano.
  • Usar procesadores XSLT basados en JS o WebAssembly del lado del cliente (aunque el código envoltorio y los ejemplos siguen siendo inmaduros).
  • Dar estilo a XML/RSS directamente con CSS, aceptando limitaciones.
  • Sustituir la plantilla XSLT por técnicas basadas en JS (p. ej., document.currentScript + APIs del DOM) u otros motores de plantillas.

Debate más amplio sobre XML/XHTML/XSLT

  • Algunos lamentan una “futura XML/XHTML” perdida con esquemas, plantillas del lado del cliente y una modularidad más limpia.
  • Otros sostienen que XHTML/XML/XSLT tenían herramientas deficientes, curvas de aprendizaje pronunciadas, sintaxis verbosa y nunca lograron adopción masiva.
  • El XML/XHTML estricto frente al HTML permisivo se debate intensamente; la estricta se ve tanto como una ventaja (errores claros) como una barrera (contenido frágil).