Proponen eliminar las menciones a XSLT de la especificación HTML

 (github.com/whatwg)
2 puntos por GN⁺ 2025-08-20 | 1 comentarios | Compartir por WhatsApp
  • Se ha propuesto un Pull Request para eliminar las menciones relacionadas con XSLT del documento del estándar HTML
  • El autor de la propuesta explica que se han reportado bugs de implementación relacionados en los principales navegadores, como Chrome, Firefox y Safari, y que también hay temas pendientes de pruebas y documentación
  • Las opiniones en contra señalan problemas de compatibilidad con sitios web existentes y un problema de legibilidad por el cual los documentos XML podrían romperse al eliminar <?xml-stylesheet?>
  • Algunos desarrolladores enfatizan que XSLT todavía se usa en documentos gubernamentales, RSS y entornos embebidos
  • También se plantea la preocupación de que decisiones centradas en grandes vendors de navegadores puedan llevar a una reducción de la apertura de la web y de su diversidad histórica

Resumen del Pull Request

  • Título del PR: Remove mentions of XSLT from the html spec
  • Autor: mfreed7
  • Destino: whatwg/html:main
  • Issue relacionado: #11523
  • Existen reportes de bugs de implementación relacionados en Chromium, Gecko y WebKit
  • Está previsto actualizar materiales relacionados como la documentación de MDN y HTML AAM

Principales opiniones en contra

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

  • Sostiene que deben considerarse las estadísticas de uso y el tamaño de los sitios web
    • Los sitios grandes pueden actualizarse, pero los sitios pequeños o personales muchas veces no se mantienen desde hace décadas, lo que genera preocupación por una ruptura permanente de compatibilidad
  • Eliminar XSLTProcessor() solo limitaría una función de JS, pero quitar <?xml-stylesheet?> provocaría que los documentos XML ni siquiera se muestren
  • Señala que funciones HTML antiguas (<font>, <align>, <xmp>) siguen funcionando, mientras que este sería un cambio sin precedentes que rompe el documento mismo
  • Destaca el riesgo de bloquear el acceso a materiales importantes como archivos antiguos y sitios universitarios

nomis (2025-08-18)

jonsterling (2025-08-18)

  • Critica la realidad en la que los vendors de navegadores definen de forma casi exclusiva la plataforma web
  • Advierte que XSLT todavía contribuye a usos diversos y creativos de la web, y que eliminarlo debilitaría la Web Abierta
  • Enfatiza el principio de que "la web es de todos" y sostiene que es necesario respetar su historia y diversidad

Apoyos y acciones de seguimiento

  • domenic (2025-08-19): respondió positivamente y señaló la necesidad de actualizar también las menciones a XSLT en la especificación DOM
  • mfreed7 (2025-08-19): respondió que enviará un PR separado también para la especificación DOM

Resumen

  • La eliminación de XSLT es un cambio propuesto como parte de los esfuerzos por simplificar y modernizar los navegadores
  • Sin embargo, quienes se oponen temen daños a la compatibilidad de documentos existentes, el acceso a datos gubernamentales y académicos, y la diversidad de la web abierta
  • Esta discusión va más allá de una simple elección técnica y se está extendiendo a un debate filosófico sobre quién tiene la autoridad para decidir los estándares web

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-20
Comentarios en Hacker News

  • Hay varios puntos llamativos

    • Esta decisión no es una acción unilateral de Chrome; en el seguimiento del issue y en las actas de reuniones de estándares relacionadas se puede confirmar que representantes de todos los navegadores principales expresaron su apoyo

    • La propuesta más reciente también fue hecha por un ingeniero de Mozilla

    • Que se haya enviado el PR no significa que se vaya a fusionar de inmediato; todavía quedan bastantes tareas sin resolver

    • Pero, dado que varios proveedores de navegadores están de acuerdo, es probable que se fusione

    • El issue sobre si se debe eliminar XSLT de la plataforma web no es para recopilar opiniones de la comunidad, sino un hilo de discusión para quienes mantienen la especificación HTML

    • Ese issue lo abrió un ingeniero de Chrome, pero los ingenieros de Mozilla ya habían planteado este tema varias veces en reuniones, y lo importante es que ya existía consenso entre los vendors

    • Ya se descubrió una vulnerabilidad de seguridad grave

    • El maintainer principal de libxslt incluso renunció personalmente

    • Quité la palabra Chrome del título

    • El título enviado originalmente era "Chrome intends to remove XSLT from the HTML spec"

    • Según los datos de telemetría de Chrome, casi no hay sitios web que realmente usen XSLT

    • Al menos los datos permiten confirmar que la propuesta no tendría un gran impacto en toda la web

    • Soy un desarrollador que trabajó antes en Mozilla y Google (equipo de Chrome)

    • Entiendo que Chrome/Blink, Safari/Webkit y Firefox/Gecko apoyan eliminar XSLT, pero dos de esos proyectos tienen falta de recursos, y uno de ellos tiene una fuerte tendencia a meter funciones nuevas a la fuerza

    • También hay motivos por los que desarrolladores de Safari y Firefox podrían ver con buenos ojos este cambio

    • Lo importante no es si “personas con autoridad creen que es una buena idea”, sino si “esta idea tendrá un impacto negativo en la plataforma web y en miles de millones de usuarios”

    • Incluso si solo el 0.1% de miles de millones depende de ello, sigue siendo una escala considerable

    • Si nadie lo usa, tampoco habría motivo para que exista un polyfill

    • No es deseable plantearlo como un juego de suma cero en el que, para agregar una función nueva, necesariamente haya que quitar una existente

    • Google está eligiendo deliberadamente no dar soporte a XSLT, a pesar de tener capital y personal suficientes

    • A menudo ha habido casos en los que algo se impulsa de inmediato porque varios vendors están de acuerdo

    • Así pasó con la eliminación de confirm/prompt, pero al final quedó pospuesta indefinidamente

    • En Google existe un documento formal del proceso para retirar funciones
      Google feature removal doc

    • El “apoyo unilateral de los vendors” no revisó adecuadamente el uso real

  • Por los dos hilos que leí, Google pidió feedback, pero casi todo el feedback fue “no lo hagan”

    • Aun así, la respuesta de Google fue algo como: “gracias por sus opiniones, ¡igual lo vamos a hacer!”

    • Si el tema era seguridad, había muchas alternativas: financiar el proyecto open source, cambiar a una librería más segura o mantenerlo dentro de un sandbox de JS, pero casi todas fueron ignoradas

    • También hubo solicitudes constantes para soportar versiones modernas como XSLT 3.0, pero no se reflejaron

    • Aunque XSLT es una tecnología que respalda la web abierta, Google lleva 10 años reduciendo su soporte y dejándola abandonada, y ahora sigue intentando eliminarla citando su baja adopción

    • Justo cuando XSLT está recuperando popularidad, da la impresión de que quieren matarlo antes de que aparezcan competidores abiertos

    • Issue relacionado

    • Sobre la afirmación de que mucho del feedback era “no lo hagan”, ese hilo se cerró temprano por comentarios de mala fe, ataques personales y similares

    • Los comentarios del tipo “esto es una buena idea” normalmente no se publican tanto, así que puede parecer que solo hay oposición

    • Todo el mundo terminó usando un tono extremo y por eso la discusión se cortó; se lo buscaron ellos mismos

    • Si las opiniones de “por favor no lo hagan” no vienen de usuarios reales o no pueden explicar por qué es indispensable, es razonable que el equipo de desarrollo las ignore

    • Pedir feedback no es una simple votación a favor o en contra

    • Estaría bien si se pudiera trasladar el soporte de XSLT 3.0 a un sandbox de JS/wasm

    • Habría una pequeña pérdida de rendimiento, pero se podrían aprovechar las ventajas de ambos lados

    • XML, por sus características como esquemas versionados y namespaces, resulta relativamente fácil de integrar

    • A diferencia de frameworks de JS como Angular, permite contratos de datos muy confiables

    • Gracias a la madurez de la familia XML, hay muchas herramientas especializadas, así que en la práctica ni siquiera hace falta manipular XML/XSD directamente como texto

    • Google usa la forma de “hacer preguntas” para avisar de antemano qué va a pasar en la web

  • Presentación de hilos anteriores relacionados

  • Me pregunto si realmente hace falta que el navegador tenga soporte integrado para un motor de plantillas específico (XSLT)

    • No es un motor de texto como Jinja, y también se podría reimplementar en JS/wasm

    • Hoy los navegadores son demasiado pesados, y desarrollar motores nuevos es difícil

    • Ojalá existiera un estándar más simple para un “navegador mínimo” con solo lo esencial, como etiquetas básicas y layout

    • WebAudio, Canvas y similares también podrían implementarse como módulos wasm (y así además se podría evitar el fingerprinting)

    • XSLT es una “spec” para un motor de plantillas, no un motor específico; existen varias implementaciones

    • Mozilla usa transformiix en lugar de libxslt

    • Jinja trabaja solo con texto, mientras que XSLT opera a nivel de nodos y es muy superior en eso

    • Las transformaciones en JS son mucho más lentas que las transformaciones nativas con XSLT, y además es más difícil cachear resultados

    • Entiendo la percepción de que XSLT es anticuado, pero durante los últimos 20 años ha sido un arma secreta en términos de rendimiento

    • Al final, es muy probable que Google intente tapar el problema con una alternativa como AMP

    • Los navegadores son pesados por culpa de Google

    • XSLT es el lenguaje (la spec), no el motor

    • Cambiar la implementación a JS/wasm es un asunto de implementación interna, no lo que ocurre cuando se elimina el lenguaje de la plataforma web

    • Audio o canvas son funciones fundamentales de I/O del navegador; moverlas a wasm causaría problemas serios de rendimiento y compatibilidad

    • Tal vez parte del audio podría llevarse a un blob wasm, pero moverlo todo sería difícil

    • El contexto de canvas o WebGL depende de la integración directa con la GPU, así que no se puede materializar en wasm

    • Al final estas funciones ya son, en la práctica, APIs primitivas básicas, así que no son negociables

    • También se discutió la idea de empaquetar código XSLT antiguo en wasm para mantener compatibilidad sin romper sitios viejos

    • De hecho se evaluó internamente, pero se decidió no hacerlo

    • Creo que funciones muy poco usadas y alejadas del uso común de la web sí pueden ser candidatas a eliminación

    • Pero no estoy de acuerdo con usar vulnerabilidades de seguridad como justificación

    • Sin siquiera verificar si existe un paquete memory-safe, el argumento pierde fuerza

    • Hay quien afirma que la tasa real de uso está en el 0.001%

  • Romper la promesa básica de la spec de HTML es un asunto muy serio

    • Sorprende incluso que la discusión no profundice más en ese punto

    • HTML era la promesa de “esto es HTML, puedes confiar en ello”, pero ahora pasa a ser “es HTML por ahora, no hay garantía de que siga siéndolo en el futuro”

    • Si se aplica la lógica para eliminar XSLT, otras tecnologías antiguas también podrían seguir siendo recortadas

    • Al final, es una propuesta para cortar la “long tail” de la web

    • También hay que pensar que muchas tecnologías web añadidas después acabarán convirtiéndose en otra long tail y generarán más candidatos a eliminación

    • En cuanto al soporte para medios y software antiguos, creo que en algún momento habrá que resolverlo con portabilidad, emulación, archivado y similares

    • Hace falta un equilibrio entre dar suficiente tiempo y herramientas para adaptarse, y evitar la acumulación gradual de complejidad

    • Si se ve lo que realmente se eliminó en el PR, no parece haber una norma explícita en HTML que exija soporte para XSLT

    • Más bien lo que hay es una fuerte reacción al tema del soporte del navegador

    • El PR en sí es sorprendentemente corto

    • Al definir WHATWG a HTML como un “Living Standard”, en la práctica ya no funciona como un estándar de implementación, sino como una forma de compartir el estado actual de lo que los vendors de navegadores están construyendo

    • Por eso también se eliminó la nomenclatura de versiones como HTML5 y se dejó únicamente “HTML”

    • Living Standard FAQ

    • HTML standard FAQ

    • Irónicamente, uno de los principales responsables de meter una enorme cantidad de funciones en las specs de HTML/CSS/navegadores ha sido justamente Google

    • Si Google hubiera defendido consistentemente que “los navegadores deben ser livianos y las cosas raras deben delegarse a librerías de JS”, esta medida podría entenderse; pero claramente no es el caso

  • Desde que se eliminó el soporte para FTP, el destino de XSL ya estaba prácticamente anunciado

    • Los navegadores tienden a priorizar por encima de todo la reducción de la superficie de ataque

    • Me da la impresión de que los siguientes candidatos a eliminación podrían ser atributos de animación SVG SMIL, MathML y otras funciones relacionadas con XML

    • Hilo relacionado

    • SMIL permite controlar animaciones secuenciales en función de tiempos específicos de inicio y fin, algo que las animaciones CSS todavía no cubren bien

    • En CSS no hay otra forma más que usar cálculos para el timing

    • Chromium incluso expresó en algún momento su intención de eliminar SMIL, pero fue demasiado apresurado porque CSS todavía no era suficiente

    • Como consecuencia, varios documentos y guías relacionados con SMIL quedaron abandonados sin actualizarse

    • Me gustaría cuestionar si reducir la superficie de ataque realmente es algo bueno o malo

    • Los ingenieros y los usuarios comunes tienen prioridades distintas

    • Me pregunto cuándo se eliminó exactamente la función FTP

    • Según entiendo, todavía se puede acceder a ftp:// desde la barra de direcciones

  • Las implementaciones de XSLT en Blink y WebKit son muy ineficientes

  • Lamento esta decisión, pero me entristece aún más que no se haya invertido en una integración más moderna de XSLT

    • Su uso era incómodo, pero si hubiera evolucionado un poco más dentro del navegador, podría haberse convertido en un competidor de frameworks como React

    • XML, sin toda la complejidad corporativa que lo rodeó, era una tecnología y un estándar realmente potentes y elegantes

    • Me encantaba usar XSLT para transformar directamente xml/datos pequeños y simples a html

    • Da pena pensar que, con solo una pequeña función adicional para mostrar distinto los elementos seleccionados, habría podido servir para muchos usos, incluso en documentos estáticos

  • Dicen que @whatwg bloqueó ese issue solo para colaboradores alegando que la discusión “se calentó demasiado”

    • A simple vista parecía bastante razonable y tranquila, así que uno se pregunta si el criterio de “acalorado” cambia según si favorece a cierto vendor o no

    • La expresión “se calentó demasiado” a menudo se interpreta como que no quieren lidiar con opiniones contrarias

    • Pasa lo mismo en otras comunidades como Reddit

    • De hecho, el único comentario que quedó debajo fue uno de un desarrollador de Google Chrome diciendo “buen trabajo”

    • Da una impresión un poco incómoda

    • Se mencionó que en el issue tracker se acumularon insultos, teorías conspirativas y mensajes políticos usados para cuestionar el problema

    • En esas condiciones se vuelve imposible tener una discusión productiva, y los mantenedores del repositorio no tienen más remedio que frenarla rápido

    • Escuché que en realidad quien bloqueó la discusión en ese repositorio fue un empleado de Apple

    • Pero la gente termina atribuyéndoselo al empleado de Google que planteó el issue

    • Últimamente Google ha promovido discusiones abiertas diciendo que quiere escuchar a la comunidad, pero después intenta seguir adelante ignorando todas las opiniones

    • Issue relacionado

  • Hace falta una reflexión más amplia sobre los elementos web heredados

    • En mi caso, sigo obteniendo mucho valor de que páginas web antiguas continúen funcionando bien

    • Gracias a que HTML/JS han mantenido la compatibilidad, incluso páginas de hace décadas siguen funcionando bien si solo se les agrega un certificado TLS

    • Pero tampoco es posible soportar para siempre todas las tecnologías heredadas

    • Al final, con Flash se terminó pasando a emuladores como Ruffle para revivir juegos o sitios antiguos

    • A largo plazo, usar navegadores o emuladores especializados en renderizado antiguo también podría ser una alternativa

    • Ya apareció una extensión polyfill de XSLT para esto

    • Chrome no quiere distribuirla oficialmente ni encargarse de su mantenimiento

    • Es una situación muy similar a la de Ruffle