- La eliminación del soporte de XSLT en Chrome es una medida de Google que debilita una tecnología central de la web abierta; aunque se justificó por temas de seguridad, se quitó la función sin ofrecer una tecnología de reemplazo
- Google propuso un polyfill basado en JavaScript en lugar de una función nativa del navegador, pero no lo integró en el navegador y trasladó la carga de implementación a los desarrolladores
- Esta decisión lleva al debilitamiento del ecosistema web independiente basado en RSS y XML, y Mozilla y Apple también se están moviendo en una dirección similar
- El texto critica que WHATWG ya no puede cumplir el papel de guardián de la web abierta y que controla los estándares web en función de los intereses de las grandes empresas
- Con la reducción de la extensibilidad del navegador y la estandarización del DRM, se está consolidando una estructura web en la que se debilita el control del usuario, y frente a ello se llama a la resistencia y al uso continuo de tecnologías abiertas como RSS, XSLT y JPEG XL
Fin del soporte de XSLT y la postura de Google
- Google retiró el soporte de XSLT en Chrome y alegó vulnerabilidades de seguridad, pero no presentó bibliotecas alternativas ni propuestas de mejora
- Se critica que usó como excusa los problemas de seguridad de bibliotecas FLOSS existentes
- También se señala que ni siquiera aprovechó la oportunidad de adoptar una implementación moderna de XSLT escrita en un lenguaje más seguro
- El polyfill en JavaScript propuesto por Google se ofrece solo mediante llamadas externas y no integrado en el navegador, por lo que se considera una alternativa no estándar e ineficiente
- El texto sostiene que esta medida es un acto deliberado para debilitar la base de la web independiente basada en RSS y XML
- Analiza que, si el polyfill no es suficiente, o incluso si lo fuera, la razón por la que Google no lo integra es desincentivar el uso mismo de XSLT
“Do. Not. Comply.” — llamado a la resistencia
- El autor enfatiza que no se debe aceptar la instalación de polyfills ni modificar XML, sino exigir la restauración del soporte de XSLT en el navegador
- Planea seguir usando tecnologías estándar como XSLT, MathML, SVG y SMIL, y mantener cajas de advertencia (infoboxes) para informar a los usuarios sobre comportamientos no estándar del navegador
- Se explica que la decisión de Google no responde a motivos técnicos sino a motivaciones políticas y comerciales, como parte de un intento de controlar la web abierta
- También critica que Mozilla y Apple avanzan en una dirección similar y que diseñan los navegadores no como agentes de usuario (User Agent) sino como herramientas del capitalismo de vigilancia
WHATWG y la distorsión de los estándares web
- WHATWG comenzó como un organismo para la web abierta, pero se considera que hoy se ha convertido en una organización cerrada centrada en las grandes empresas
- Se evalúa que este grupo está transformando la web de un repositorio de conocimiento a una plataforma de distribución de aplicaciones, priorizando la maximización de ingresos corporativos por encima del control del usuario
- El navegador ya no funciona como representante del usuario (User Agent), sino como una herramienta de control al servicio de los intereses empresariales
- Se señala que este cambio choca de frente con la visión de una web abierta que promovía el W3C
La necesidad de una nueva guerra de navegadores
- El mercado actual de navegadores tiene una estructura dependiente de motores dominada por Google, Apple y Mozilla, con muy pocas alternativas independientes
- Se mencionan navegadores alternativos como Vivaldi, LibreWolf, WaterFox y Pale Moon, pero la mayoría depende de los motores Blink o Gecko
- Pale Moon es evaluado como uno de los pocos navegadores que mantiene soporte para RSS y JPEG XL
- El texto sostiene que hace falta una nueva guerra de navegadores: una guerra de los usuarios contra las corporaciones para recuperar el control de la web
La posibilidad de otra web — Gemini y los protocolos abiertos
- Además de la web centrada en HTTP y HTML, existen nuevos espacios de internet como el protocolo Gemini
- Gemini es un protocolo ligero con una estructura simple y funciones integradas de seguridad y autenticación, operado fuera de la esfera de influencia de Google
- Sin embargo, se enfatiza que el problema no es la tecnología sino la estructura social, y que la tecnología en sí sigue siendo válida
- Se plantea que los navegadores no deberían discriminar según el protocolo o el formato, y que sería deseable un soporte integrado para formatos de marcado ligeros como Markdown, AsciiDoc y Gemtext
La eliminación de plugins y el refuerzo del control sobre la web
- En el pasado, la interfaz de plugins NPAPI permitía soportar diversos formatos y protocolos, pero Google empezó a retirarla gradualmente desde 2013
- Como resultado, se bloqueó la extensibilidad de la web y la vía para introducir tecnologías experimentales
- Se critica que Encrypted Media Extensions (EME), que apareció tras la eliminación de los plugins, estandarizó el DRM y dañó los principios de apertura del W3C
- Las extensiones del navegador son, bajo el argumento de la seguridad, sustitutos con funciones limitadas; en particular, Manifest V3 debilita la capacidad de bloqueo de anuncios
- Se analiza que estos cambios llevaron a una reducción del control del usuario y un fortalecimiento del control corporativo
“A mesh of building blocks” — la estructura web ideal
- La web ideal debería tener una estructura modular basada en plugins, donde se puedan añadir libremente nuevos protocolos, formatos y lenguajes de scripting
- Se menciona que, de haber sido así, RSS, SMIL, XSLT, XQuery y XHTML2 habrían seguido evolucionando
- Pero la realidad cambió hacia una estructura en la que Google decide de forma monopólica la dirección de evolución de la web, y se concluye que hace falta una resistencia impulsada por los usuarios para revertirlo
Resist — declaración de resistencia
- Bajo el lema “Do not comply. Resist.”, se llama a las siguientes acciones
- Seguir usando RSS
- Seguir utilizando XSLT
- Adoptar JPEG XL como formato de imagen predeterminado
- Considerar el comportamiento no estándar del navegador como un ‘defecto del navegador’ y no como un ‘error del sitio’
- Se presenta esto no como una simple elección técnica, sino como una resistencia práctica para defender la web abierta
Post Scriptum y reacciones
- Se presentan xslt.rip y el sitio personal del autor como proyectos relacionados con XSLT, y se menciona un intento de generar SVG con XSLT
- Hubo debates en Hacker News y Lobste.rs, pero se señala que muchos comentarios subestimaron la importancia de XSLT
- El autor enfatiza que XSLT es más eficiente que el renderizado en servidor, especialmente en entornos pequeños y autohospedados
- En conclusión, se reafirma que el uso continuo de tecnologías abiertas como XSLT es una estrategia clave para la supervivencia de la web abierta
3 comentarios
Dicen que por qué no lo integran, pero por otro lado tampoco parece haber una razón para integrarlo a la fuerza..
Opiniones de Hacker News
Eliminar XSLT del navegador era algo necesario desde hace mucho tiempo
Como exmantenedor de libxslt, conozco hasta cierto punto el trasfondo que llevó a esta decisión
Lo más interesante es que Chromium planea cambiar a un parser XML basado en Rust
Actualmente prefieren xml-rs, pero este solo implementa una parte de XML
Es decir, parece que Google quiere optar por un soporte XML que no cumple completamente con el estándar
Me recuerda a la época de Internet Explorer 5.1, cuando se ignoraban los estándares gracias a la cuota de mercado
Desde que XHTML fue desplazado por HTML5, el código complejo relacionado con XML ha ido desapareciendo de forma natural
Pasarlo a Rust para reducir la superficie de ataque de seguridad es una decisión razonable
El parsing XML que quede se puede reemplazar en JS con polyfills o wasm
Trabajo en el equipo de Chrome, pero no participo directamente en esta tarea
Antes, la web giraba en torno a quien administraba el sitio, y el navegador era su herramienta (sirviente)
La dirección actual se está alejando de esa filosofía
XML permite vulnerabilidades de explosión de datos como el ataque Billion Laughs
Explicación relacionada
La afirmación de que XSLT es indispensable para ver feeds RSS en el navegador está exagerada
Con JavaScript también es perfectamente posible, y el polyfill de Google funciona así
He escrito miles de líneas de XSLT, pero creo que JavaScript es mucho mejor
XSLT ya debería eliminarse por razones de seguridad
Esto se trata en una ponencia relacionada en OffensiveCon 2025
Las funciones equivalentes en JS son complejas y tienen una barrera de entrada alta
A medida que se vuelve más difícil crear páginas web personales simples, se debilita el espíritu de la ‘web abierta’
La desaparición de RSS y la dependencia de plataformas como Facebook son consecuencia de eso
Véase la documentación de Web Components
Recuerdo que navegadores independientes desaparecieron por no poder seguir el ritmo del ecosistema JS, que evolucionaba rápidamente
Extraño al viejo Konqueror
document()Después de verla, sentí que eliminar XSLT sí tenía sentido
habría que soportar una forma como
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;Pero con la implementación actual, es difícil reemplazar por completo con JS una experiencia al nivel de XSLT
Estoy de acuerdo con la idea de que Google está matando la web abierta, pero XSLT es una base débil para sostener ese argumento
Parece una decisión para reducir recursos de mantenimiento en una función compleja que casi no se usa
Para mostrar feeds RSS/Atom, sería mejor agregar soporte directo al navegador
No debería juzgarse solo por la frecuencia de uso
Habría que trabajar con usuarios importantes para retirarlo de forma gradual
La “web abierta” y XSLT no tienen mucho que ver
La web abierta significa un entorno donde cualquiera puede operar un servidor, crear un sitio y desarrollar un navegador
XSLT es una tecnología que ya murió hace mucho, y casi no habrá sitios que se rompan por su eliminación
Más bien, tiene el efecto de eliminar vulnerabilidades de seguridad
El problema no era XSLT en sí, sino que la implementación de libxslt tenía vulnerabilidades
Se podía haber creado una implementación alternativa, pero el problema es que Google eligió ‘matar’ la función
Solo que ahora la gente prefiere el consumo basado en feeds sociales antes que suscribirse a sitios individuales
No es un problema técnico, sino un cambio en el comportamiento del usuario
Entre quienes se quejan de la eliminación de XSLT, casi nunca he visto a alguien explicar con claridad por qué lo usa realmente
En la mayoría de los casos se menciona solo como un símbolo de resistencia
Durante más de 20 años existió la expectativa de que “las páginas web se verán para siempre”
Como el mantenedor de libxslt renunció por la carga de los reportes de seguridad,
los fabricantes de navegadores eligieron eliminar la función en lugar de pagar el costo
Usarla como símbolo de rebeldía es una forma de hacerse sufrir a uno mismo
Si hace falta, se puede reemplazar suficientemente con un polyfill o con transformación del lado del servidor
Lo usaba para transformar feeds RSS/Atom en algo más agradable de ver
En el sitio rss.style que hice se puede ver esa diferencia
Mozilla eliminó RSS no por presión de Google,
sino porque los usuarios no querían RSS
De hecho, Google es una de las empresas que más ha invertido en el desarrollo de la web abierta
Que WHATWG quiera convertir la web en una plataforma de aplicaciones es resultado de la demanda de desarrolladores y usuarios
Blink es código abierto, así que incluso se puede mantener un fork
RSS era demasiado técnico para el público general, y cuando Google eliminó Reader,
las redes sociales ocuparon ese lugar
pero al final reforzó una estructura monopólica
Que Blink sea open source no garantiza por sí solo una apertura real
si su sola existencia no hace daño, no hay necesidad de eliminarla
Entiendo parte del argumento del autor,
pero decir que el navegador debería soportar hasta Gopher es exceso de complejidad
Desde la perspectiva del proyecto Chrome, parece una decisión para simplificar
Eliminarlo es razonable, y la mayoría de quienes trabajan en la industria web está de acuerdo
El parsing XML basado en C siempre da miedo desde el punto de vista de seguridad
extensión (extension) en lugar de eliminarla por completo
elimine funciones antiguas con el argumento de simplificar es contradictorio
En cualquier caso, alguien termina perdiendo
Estoy pensando en convertir mi blog a XML/XSLT
Como nadie lo lee, ahora podré culpar a Chrome por la falta de tráfico
No soy fan de Google, pero eliminar XSLT es una oportunidad para reducir la complejidad de las APIs web
Para navegadores independientes como Ladybird, podría reducir la carga
Al final, incluso podría debilitar el monopolio de Google
así que cuesta decir que esto avanza “sin gran resistencia”
En los últimos 10 a 15 años, los estándares web han seguido una tendencia de meter en el navegador requisitos de nicho
La eliminación de XSLT y la oferta de un polyfill parecen ir en la dirección de empujar la complejidad fuera del navegador
Es curioso ver un texto que dice que hay que dar soporte a XSLT en 2025... Es cierto que se usa por momentos para dar estilo a cosas como RSS, pero cuesta decir que se use mucho de forma general.