- A descontinuação do suporte a XSLT no Chrome é apresentada como uma medida que enfraquece uma tecnologia central da web aberta; embora o motivo alegado tenha sido segurança, o recurso foi removido sem oferecer uma tecnologia substituta
- O Google sugeriu um polyfill baseado em JavaScript em vez de uma funcionalidade nativa do navegador, mas não o incorporou ao browser e transferiu aos desenvolvedores o custo de implementação
- Essa decisão leva ao enfraquecimento do ecossistema independente da web baseado em RSS e XML, e Mozilla e Apple também estariam seguindo rumo semelhante
- O texto critica o WHATWG por não cumprir mais o papel de guardião da web aberta e por controlar os padrões da web com foco nos interesses das grandes empresas
- Com a redução da extensibilidade dos navegadores e a padronização do DRM, consolida-se uma estrutura da web em que o controle do usuário é enfraquecido; em resposta, o autor defende a continuidade no uso e a resistência em favor de tecnologias abertas como RSS, XSLT e JPEG XL
Fim do suporte a XSLT e a postura do Google
- O Google está descontinuando o suporte a XSLT no Chrome e citou vulnerabilidades de segurança como motivo, mas não apresentou biblioteca substituta nem plano de melhoria
- O texto critica a empresa por usar como pretexto problemas de segurança em bibliotecas FLOSS já existentes
- Também aponta que a empresa sequer aproveitou a oportunidade de adotar implementações modernas de XSLT escritas em linguagens mais seguras
- O polyfill em JavaScript proposto pelo Google é oferecido apenas por chamadas externas, sem integração nativa ao navegador, sendo avaliado como uma alternativa não padronizada e ineficiente
- O texto sustenta que essa medida é uma ação deliberada para enfraquecer a base da web independente construída sobre RSS e XML
- A análise afirma que, se o polyfill não for suficiente, ou mesmo que seja, o fato de o Google não incorporá-lo ao navegador revela o objetivo de desencorajar o próprio uso de XSLT
“Do. Not. Comply.” — um chamado à resistência
- O autor enfatiza que não se deve aceitar a instalação de polyfills nem modificar XML, e sim exigir a restauração do suporte a XSLT no navegador
- Ele pretende continuar usando tecnologias padronizadas como XSLT, MathML, SVG e SMIL, além de manter uma caixa de aviso (infobox) para informar os usuários sobre o comportamento não padronizado dos navegadores
- A decisão do Google é descrita não como técnica, mas como motivada por interesses políticos e comerciais, parte de uma tentativa de controlar a web aberta
- Mozilla e Apple também estariam caminhando na mesma direção, sendo criticadas por projetar navegadores não como User Agents, mas como ferramentas de capitalismo de vigilância
WHATWG e a distorção dos padrões da web
- O WHATWG é descrito como um fórum que no início existia em defesa da web aberta, mas que hoje teria se transformado em uma organização fechada centrada nas grandes empresas
- Segundo o texto, o grupo está convertendo a web de repositório de conhecimento em plataforma de distribuição de aplicações, priorizando a maximização do lucro corporativo em vez do controle do usuário
- O navegador deixaria de ser um User Agent para funcionar como instrumento de controle a serviço dos interesses corporativos
- O autor afirma que essa mudança colide frontalmente com a visão de web aberta defendida pelo W3C
A necessidade de uma nova guerra dos navegadores
- O mercado atual de navegadores é descrito como uma estrutura dependente de engines centradas em Google, Apple e Mozilla, com pouquíssimas alternativas independentes
- Navegadores como Vivaldi, LibreWolf, WaterFox e Pale Moon são mencionados, mas a maioria depende de Blink ou Gecko
- O Pale Moon é apontado como um dos poucos navegadores que mantêm suporte a RSS e JPEG XL
- O texto argumenta que é necessária uma nova guerra dos navegadores — uma guerra dos usuários contra as empresas para retomar o controle da web
Outra possibilidade de web — Gemini e protocolos abertos
- Além da web centrada em HTTP e HTML, existem outros espaços de internet, como o protocolo Gemini
- O Gemini é apresentado como um protocolo leve, de estrutura simples, com recursos embutidos de segurança e autenticação, operando fora da esfera de influência do Google
- No entanto, o autor ressalta que o problema não é a tecnologia, mas a estrutura social, e que a tecnologia em si continua válida
- Os navegadores não deveriam discriminar por protocolo ou formato, e o texto propõe como desejável o suporte integrado a formatos leves de marcação como Markdown, AsciiDoc e Gemtext
Remoção de plugins e reforço do controle sobre a web
- No passado, a interface de plugins NPAPI permitia suporte a vários formatos e protocolos, mas o Google começou a removê-la gradualmente a partir de 2013
- Com isso, teriam sido bloqueados tanto a extensibilidade da web quanto o caminho para adoção de tecnologias experimentais
- O texto critica as Encrypted Media Extensions (EME), que surgiram após a remoção dos plugins, por padronizarem o DRM e ferirem os princípios de abertura do W3C
- As extensões de navegador são descritas, sob o pretexto da segurança, como substitutos limitados, e o Manifest V3 em especial enfraqueceria as capacidades de bloqueio de anúncios
- A análise conclui que essas mudanças levaram à redução do controle do usuário e ao fortalecimento do controle corporativo
“A mesh of building blocks” — a estrutura ideal da web
- A web ideal seria uma estrutura modular baseada em plugins, capaz de adicionar livremente novos protocolos, formatos e linguagens de script
- Nessa estrutura, RSS, SMIL, XSLT, XQuery e XHTML2 poderiam ter continuado a evoluir
- Mas a realidade teria se transformado em uma estrutura na qual o Google decide de forma monopolista a direção da evolução da web, e o texto conclui pela necessidade de resistência liderada pelos usuários para reverter isso
Resist — declaração de resistência
- Sob o lema “Do not comply. Resist.”, o texto conclama às seguintes ações
- Continuar usando RSS
- Continuar usando XSLT
- Adotar JPEG XL como formato de imagem padrão
- Tratar comportamentos não padronizados do navegador como ‘defeito do navegador’, e não como ‘erro do site’
- Isso é apresentado não como simples escolha técnica, mas como uma resistência prática para defender a web aberta
Post Scriptum e reações
- O texto apresenta os projetos de XSLT xslt.rip e o site pessoal do autor, mencionando tentativas de gerar SVG com XSLT
- Houve discussões no Hacker News e no Lobste.rs, mas o autor afirma que muitos comentários subestimaram a importância do XSLT
- O autor reforça que XSLT é mais eficiente do que renderização no servidor, especialmente em ambientes pequenos e self-hosted
- Em conclusão, reafirma que o uso contínuo de tecnologias abertas como XSLT é uma estratégia central para a sobrevivência da web aberta
3 comentários
Dizem: por que não embutir? Mas, por outro lado, também não parece haver um motivo real para precisar embutir..
Opinião no Hacker News
A remoção do XSLT do navegador é algo necessário há muito tempo
Como ex-mantenedor do libxslt, eu conheço em certa medida o contexto que levou a essa decisão
O mais interessante é que o Chromium planeja migrar para um parser XML baseado em Rust
No momento, a preferência é pelo xml-rs, que implementa apenas parte do XML
Ou seja, parece que o Google pretende adotar um suporte a XML que não segue totalmente o padrão
Isso lembra os tempos do Internet Explorer 5.1, quando a participação de mercado permitia ignorar padrões
Desde que o XHTML perdeu espaço para o HTML5, códigos complexos relacionados a XML vêm desaparecendo naturalmente
Migrar para Rust para reduzir a superfície de ataque de segurança é uma escolha razoável
O parsing XML restante pode ser substituído em JS com polyfill ou wasm
Eu trabalho na equipe do Chrome, mas não estou diretamente envolvido neste trabalho
No passado, quem mandava eram os operadores dos sites, e o navegador era sua ferramenta (servo)
A direção atual está se afastando dessa filosofia
Isso porque o XML permite vulnerabilidades de explosão de dados como o ataque Billion Laughs
Explicação relacionada
Afirmar que o XSLT é indispensável para visualizar feeds RSS no navegador é exagero
Isso também é perfeitamente possível com JavaScript, e o polyfill do Google funciona assim
Já escrevi milhares de linhas de XSLT, mas acho JavaScript muito melhor
O XSLT agora deveria ser removido por motivos de segurança
O assunto foi abordado nesta apresentação da OffensiveCon 2025
As alternativas em JS são complexas e têm barreira de entrada alta
À medida que fica mais difícil criar páginas pessoais simples, o espírito da ‘web aberta’ enfraquece
O desaparecimento do RSS e a dependência de plataformas como o Facebook são resultado disso
Veja a documentação de Web Components
Lembro de navegadores independentes que desapareceram por não conseguirem acompanhar o ecossistema de JS em rápida evolução
Sinto falta do antigo Konqueror
document()Depois disso, senti que remover o XSLT fazia sentido
seria preciso oferecer suporte a algo como
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;Mas, na implementação atual, é difícil substituir totalmente com JS a experiência que o XSLT oferece
Concordo com a afirmação de que o Google está matando a web aberta, mas XSLT é uma base fraca para esse argumento
Parece mais uma decisão para reduzir recursos de manutenção de uma funcionalidade complexa e quase sem uso
Para exibir feeds RSS/Atom, seria melhor colocar suporte direto no navegador
Não dá para julgar só pela frequência de uso
Seria preciso colaborar com usuários importantes e fazer uma descontinuação gradual
A “web aberta” e o XSLT não têm muita relação
Web aberta significa um ambiente em que qualquer pessoa pode operar um servidor, criar um site e desenvolver um navegador
XSLT já é uma tecnologia morta há muito tempo, e quase não há sites que quebrariam com sua remoção
Pelo contrário, há o efeito de eliminar vulnerabilidades de segurança
O problema não era o XSLT em si, mas vulnerabilidades na implementação do libxslt
Daria para criar uma implementação alternativa, mas o problema é que o Google escolheu ‘matar’ a funcionalidade
Só que hoje as pessoas preferem o consumo baseado em feeds sociais em vez de assinar sites individuais
Isso não é um problema técnico, e sim uma mudança no comportamento dos usuários
Quase nunca vi alguém que reclama do fim do XSLT explicar com clareza por que realmente o usa
Na maioria dos casos, ele é citado apenas como um símbolo de resistência
Por mais de 20 anos existiu a expectativa de que “as páginas da web seriam visíveis para sempre”
Como o mantenedor do libxslt renunciou por causa da carga dos relatórios de segurança,
os fabricantes de navegadores preferiram remover a funcionalidade em vez de pagar o custo
Usá-lo como símbolo de rebeldia é só uma forma de se torturar
Quando necessário, polyfill ou transformação no lado do servidor substituem isso sem problemas
Eu o usava para converter feeds RSS/Atom em algo mais agradável de visualizar
Dá para ver essa diferença no site rss.style que eu criei
A remoção do RSS pela Mozilla não aconteceu por pressão do Google,
mas porque os usuários não queriam RSS
O Google, na verdade, é uma das empresas que mais investiu no desenvolvimento da web aberta
O fato de o WHATWG querer transformar a web em uma plataforma de aplicações é resultado da demanda de desenvolvedores e usuários
O Blink é open source, então também é possível manter um fork
O RSS era técnico demais para o grande público e, quando o Google acabou com o Reader,
as redes sociais ocuparam esse espaço
mas no fim reforçou uma estrutura monopolista
O fato de o Blink ser open source não garante abertura real
se a simples existência dela não causa dano, não há necessidade de removê-la
Concordo em parte com o autor,
mas dizer que o navegador deveria até suportar Gopher é complexidade em excesso
Do ponto de vista do projeto Chrome, isso parece uma decisão de simplificação
Removê-lo é razoável, e a maioria de quem trabalha com web concorda com isso
Parsing XML baseado em C sempre transmite medo em termos de segurança
seria melhor separá-la na forma de extensão (extension)
remova recursos antigos usando a simplificação como justificativa
De qualquer forma, alguém acaba perdendo
Estou pensando em mudar meu blog para XML/XSLT
Como ninguém lê mesmo, agora vou poder culpar o Chrome pelo baixo tráfego
Não sou fã do Google, mas remover o XSLT é uma oportunidade de reduzir a complexidade das APIs da web
Para navegadores independentes como o Ladybird, isso pode aliviar a carga
No fim, isso talvez até enfraqueça o poder monopolista do Google
então é difícil dizer que isso está avançando “sem grande reação”
Nos últimos 10 a 15 anos, os padrões web caminharam no sentido de colocar no navegador certas necessidades de nicho
A remoção do XSLT com oferta de polyfill parece seguir a direção de empurrar a complexidade para fora do navegador
É interessante ver um texto dizendo que em 2025 ainda seria necessário oferecer suporte a XSLT... De fato ele é usado por um momento em estilização de RSS e afins, mas é difícil dizer que seja algo amplamente utilizado de forma geral.