Chrome e Edge estão removendo XSLT: o que quebra e o que não quebra

Artigo original ↗ Discussão no Hacker News ↗

Chrome e Edge estão descontinuando o suporte integrado a XSLT, gerando preocupação com quebras em sites baseados em XML, feeds RSS/Atom estilizados e fluxos de trabalho de nicho que dependem de transformações no lado do cliente. Os defensores da remoção argumentam que o XSLT é pouco usado, complexo de manter e representa uma superfície de segurança e ataque não trivial, especialmente com bibliotecas XML antigas, enquanto outros lamentam a perda de uma ferramenta declarativa poderosa e um símbolo da visão XML/XHTML abandonada para a web. Entre as alternativas discutidas estão transformações no servidor, motores XSLT baseados em JavaScript ou WebAssembly, ou estilização mais simples via CSS, embora muitos vejam que não há um substituto verdadeiramente equivalente.

Escopo da mudança

  • O Chrome está descontinuando e removendo o XSLT integrado; o Edge, como um fork do Chromium, deve seguir o mesmo caminho.
  • O Firefox atualmente ainda funciona, mas registra avisos e também tem uma “intenção de descontinuar” o XSLT.
  • Efeito líquido: o XSLT no navegador desaparece; o XSLT no lado do servidor permanece inalterado.

Razões apresentadas para a remoção

  • Recurso legado, raramente usado, com uma superfície de ataque grande e complexa.
  • As bibliotecas XML subjacentes são antigas, recebem pouca manutenção e têm histórico de vulnerabilidades.
  • Manter esse código para bilhões de usuários é considerado caro.
  • Alguns veem os LLMs como algo que torna a manutenção mais barata; outros argumentam que eles também reduzem o custo de encontrar explorações e não eliminam os custos de segurança/manutenção.

Ceticismo e crítica

  • Alguns veem isso como comportamento de monocultura de navegadores: fornecedores “simplesmente derrubam coisas porque não se importam”.
  • Alguns enquadram isso como um padrão semelhante ao fim do Flash: criar uma narrativa de segurança para justificar a remoção de tecnologia inconveniente.
  • Outros respondem que quase ninguém usa ou mantém XSLT hoje em dia e que é irrealista esperar suporte contínuo.

Impacto e quebra

  • UIs baseadas em XML+XSLT (por exemplo, alguns relatórios do IIS, leitores TEI/XML, feeds RSS/Atom estilizados, blogs baseados em XSLT) vão quebrar ou piorar em navegadores baseados em Chromium.
  • O Chrome já exibe um aviso destacado quando XSLT é usado.
  • Sites governamentais e regulatórios que usam XSLT são apontados como em risco (issues vinculadas).

Alternativas e caminhos de migração

  • Faça a transformação XSLT no servidor e sirva HTML simples.
  • Use processadores XSLT baseados em JS ou WebAssembly no lado do cliente (embora o código wrapper e os exemplos ainda sejam imaturos).
  • Estilize XML/RSS diretamente com CSS, aceitando as limitações.
  • Substitua a modelagem com XSLT por técnicas baseadas em JS (por exemplo, document.currentScript + APIs DOM) ou por outros motores de template.

Debate mais amplo sobre XML/XHTML/XSLT

  • Alguns lamentam um futuro perdido de “XML/XHTML”, com schemas, modelagem no lado do cliente e modularidade mais limpa.
  • Outros argumentam que XHTML/XML/XSLT tinham ferramentas ruins, curvas de aprendizado íngremes, sintaxe verbosa e nunca ganharam adoção em massa.
  • XML/XHTML estritos versus HTML tolerante é intensamente debatido; a rigidez é vista tanto como uma vantagem (erros claros) quanto como uma barreira (conteúdo frágil).