Publicado em: 29 de outubro de 2025
O Chrome pretende descontinuar e remover o XSLT do navegador. Este documento detalha como migrar seu código antes da remoção no final de 2026.
O Chromium descontinuou oficialmente o XSLT, incluindo a API JavaScript XSLTProcessor e a instrução de processamento XSLT. Pretendemos remover o suporte da versão 158 (17 de novembro de 2026). Os projetos Firefox e WebKit também indicaram planos de remover o XSLT dos mecanismos de navegação. Este documento apresenta um pouco de história e contexto, explica como estamos removendo o XSLT para tornar o Chrome mais seguro e fornece um caminho para migração antes que esses recursos sejam removidos do navegador. Para as atualizações mais recentes, consulte também a entrada do Status da Plataforma Chrome.
O que será removido?
Há duas APIs no navegador que implementam o XSLT, e ambas estão sendo removidas:
- A classe
XSLTProcessor
(por exemplo,
new XSLTProcessor()). - A instrução de processamento
XSLT
(por exemplo,
<?xml-stylesheet type="text/xsl" ... ?>).
Linha do tempo do Chrome
O Chrome tem o seguinte plano:
- Chrome 142 (28 de outubro de 2025): mensagens de aviso antecipado do console adicionadas ao Chrome.
- Chrome 143 (2 de dezembro de 2025): descontinuação oficial da API. Mensagens de aviso de descontinuação começam a aparecer no console e no Lighthouse.
- Chrome 145 (2 de dezembro de 2025 Canary): as versões Canary, Dev e Beta começam a desativar o XSLT por padrão, como um aviso antecipado.
- Chrome 146 (10 de março de 2026): a política corporativa (EP) será lançada para testes. Isso permite que as empresas testem a desativação do XSLT com antecedência e continuem usando os recursos após a data de remoção.
- Chrome 152 (25 de agosto de 2026): o teste de origem (OT) será lançado para testes. Eles permitem que sites continuem usando recursos após a data da remoção.
- Chrome 154 (22 de setembro de 2026): as versões Canary, Dev e Beta do Webview começam a desativar o XSLT por padrão, como um aviso antecipado.
- Chrome 158 (17 de novembro de 2026): o XSLT vai parar de funcionar nas versões Stable para todos os usuários, exceto para os participantes do teste de origem e da política corporativa.
- Chrome 176 (17 de agosto de 2027): o teste de origem e a política corporativa deixarão de funcionar. O XSLT está desativado para todos os usuários.
O que é XSLT?
XSLT, ou Extensible Stylesheet Language Transformations, é uma linguagem usada para transformar documentos XML, geralmente em outros formatos, como HTML. Ele usa um arquivo de folha de estilo XSLT para definir as regras dessa conversão e um arquivo XML que contém os dados usados como entrada.
Nos navegadores, quando um arquivo XML é recebido e vinculado a uma folha de estilo XSLT, o navegador usa as regras dessa folha de estilo para reorganizar, formatar e converter os dados XML brutos em uma página estruturada (geralmente HTML) que pode ser renderizada para o usuário.
Por exemplo, uma folha de estilo XSLT pode receber a seguinte entrada XML:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
e esta folha de estilo XSL:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/page/message">
<body>
<p>Message: <xsl:value-of select="."/></p>
</body>
</xsl:template>
</xsl:stylesheet>
e os processa neste HTML para que o navegador mostre: HTML
<body>
<p>Message: Hello World.</p>
</body>
Além da instrução de processamento XSL mostrada no exemplo anterior, também há a API JavaScript XSLTProcessor, que pode ser usada para processar documentos XML locais com folhas de estilo XSLT locais.
Histórico do XSLT
O XSLT foi recomendado pelo World Wide Web Consortium (W3C) em 16 de novembro de 1999 como uma linguagem para transformar documentos XML em outros formatos, mais comumente HTML para exibição em navegadores da Web. Antes da recomendação oficial da versão 1.0, a Microsoft tomou uma iniciativa antecipada ao enviar uma implementação proprietária com base em um rascunho de trabalho do W3C no Internet Explorer 5.0, lançado em março de 1999. Seguindo o padrão oficial, a Mozilla implementou o suporte nativo ao XSLT 1.0 no Netscape 6 no final de 2000. Outros navegadores importantes, incluindo Safari, Opera e, mais tarde, o Chrome, também incorporaram processadores XSLT 1.0 nativos, tornando as transformações de XML em HTML do lado do cliente uma tecnologia da Web viável no início dos anos 2000.
A linguagem XSLT continuou evoluindo, com o lançamento do XSLT 2.0 em 2007 e do XSLT 3.0 em 2017, que introduziram recursos avançados, como expressões regulares, tipos de dados aprimorados e a capacidade de processar JSON. No entanto, o suporte do navegador estagnou. Atualmente, todos os principais mecanismos de navegador da Web oferecem suporte nativo apenas ao XSLT 1.0 original de 1999. Essa falta de avanço, com o aumento do uso do JSON como formato de transmissão e de bibliotecas e frameworks JavaScript (como jQuery, React e Vue.js) que oferecem uma manipulação do DOM e uma criação de modelos mais flexíveis e eficientes, levou a um declínio considerável no uso do XSLT pelo lado do cliente. A função dele no navegador da web foi amplamente substituída por essas tecnologias baseadas no JavaScript.
Por que o XSLT precisa ser removido?
A inclusão contínua do XSLT 1.0 em navegadores da Web apresenta um risco de segurança significativo e desnecessário. As bibliotecas que processam essas transformações, como a libxslt (usada por navegadores Chromium), são bases de código C/C++ complexas e antigas. Esse tipo de código é notoriamente suscetível a vulnerabilidades de segurança de memória, como estouros de buffer, que podem levar à execução de código arbitrário. Por exemplo, auditorias de segurança e rastreadores de bugs identificaram repetidamente vulnerabilidades de alta gravidade nesses analisadores (por exemplo, CVE-2025-7425 e CVE-2022-22834, ambos em libxslt). Como o XSLT pelo lado do cliente agora é um recurso de nicho e raramente usado, essas bibliotecas recebem muito menos manutenção e análise de segurança do que os mecanismos JavaScript básicos. No entanto, elas representam uma superfície de ataque direta e potente para processar conteúdo da web não confiável. Aliás, o XSLT é a origem de vários exploits de segurança recentes e de grande repercussão que continuam colocando os usuários de navegadores em risco. Os riscos de segurança de manter essa funcionalidade legada e frágil superam em muito a utilidade moderna limitada dela.
Além disso, o propósito original do XSLT do lado do cliente, que era transformar dados em HTML renderizável, foi substituído por APIs JavaScript mais seguras, ergonômicas e com melhor manutenção. O desenvolvimento moderno da Web depende de recursos como a API Fetch para recuperar dados (normalmente JSON) e a API DOMParser para analisar com segurança strings XML ou HTML em uma estrutura DOM no sandbox JavaScript seguro do navegador. Frameworks como React, Vue e Svelte gerenciam a renderização desses dados de forma eficiente e segura. Esse conjunto de ferramentas moderno é desenvolvido ativamente, se beneficia do enorme investimento em segurança nos mecanismos JavaScript e é o que praticamente todos os desenvolvedores web usam hoje. Na verdade, apenas cerca de 0,02% dos carregamentos de páginas da Web usam XSLT, com menos de 0,001% usando instruções de processamento de XSLT.
Essa não é uma ação exclusiva do Chrome ou do Chromium: os outros dois principais mecanismos de navegação também oferecem suporte à remoção do XSLT da plataforma web: WebKit e Gecko.
Por esses motivos, a descontinuação e a remoção do XSLT reduzem a superfície de ataque do navegador para todos os usuários, simplificam a plataforma web e permitem que os recursos de engenharia se concentrem em proteger as tecnologias que realmente impulsionam a web moderna, sem perda prática de capacidade para os desenvolvedores.
Melhoria da segurança da análise de XML
Assim como os problemas graves de segurança na libxslt, problemas graves de segurança foram relatados recentemente na libxml2, que é usada no Chromium para análise, serialização e teste da formação correta do XML. Para resolver futuros problemas de segurança com a análise de XML no Chromium, planejamos descontinuar o uso da libxml2 e substituir a análise de XML por uma biblioteca de análise de XML segura para a memória escrita em Rust. É importante ressaltar que não vamos remover o XML do navegador. Somente o XSLT está sendo considerado para remoção aqui. Queremos garantir que a substituição da libxml2 seja totalmente transparente para os desenvolvedores web.
O XML + CSS não está sendo removido
É importante distinguir a descontinuação do XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) da própria instrução de processamento
<?xml-stylesheet ... ?>, que continua sendo compatível
quando usada com CSS. Ainda é possível usar a instrução de processamento com
type="text/css" para aplicar regras de layout e design padrão aos dados brutos,
assim como é possível fazer com HTML. Exemplo:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
Como migrar
Há alguns caminhos alternativos para a migração.
JSON
Para sites totalmente criados em XML e XSL, não há uma maneira única de fazer a transição. As opções de migração incluem mover o pipeline de processamento XSLT para o lado do servidor e enviar o HTML renderizado para o cliente ou migrar endpoints de API XML do lado do servidor para JSON e realizar a renderização do lado do cliente usando JavaScript para transformar JSON em DOM HTML e CSS.
XSLT do lado do cliente em JavaScript
Há algumas bibliotecas XSLT do lado do cliente (baseadas em JavaScript) disponíveis, mas a maior é produzida pela Saxonica (consulte a documentação abrangente da Saxonica). A implementação vai muito além da implementação do XSLT 1.0 em navegadores da Web, implementando suporte total ao padrão v3.0 mais recente e, por fim, ao padrão v4.0 em andamento.
Polyfill
Há um polyfill que tenta permitir que o código atual, que depende das implementações do XSLT 1.0 pelos navegadores da Web, continue funcionando sem usar os recursos nativos do XSLT do navegador. O polyfill está localizado no GitHub.
O polyfill contém uma substituição funcional baseada em WASM para a classe XSLTProcessor, de modo que o código JavaScript atual possa continuar funcionando como está:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
O polyfill também oferece uma função utilitária automática para substituir facilmente documentos XML que usam instruções de processamento XSLT:
Para um arquivo demo.xml original como este:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Uma linha pode ser adicionada para invocar o polyfill e transformar o documento com a folha de estilo XSLT referenciada:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
Nesse caso, o novo elemento <script> carrega o polyfill, que detecta o
tipo de documento XML e a instrução de processamento XSLT e o carrega de forma transparente, substituindo o documento.
Extensão
Também há uma extensão do Chrome que pode ser adicionada aos navegadores compatíveis, que vai aplicar o mesmo polyfill de XSLT a todas as páginas XML brutas que contêm instruções de processamento de XSLT ou chamadas para o XSLTProcessor. Isso pode ser usado em aplicativos em que o XML ou XSLT de origem não pode ser alterado para manter a funcionalidade.
Em particular, quando o XSLT está desativado, o Chrome mostra um banner de aviso que leva diretamente a uma página de pesquisa de extensões para ajudar os usuários a localizar uma:
Casos de uso específicos
Na discussão sobre os padrões HTML, vários casos de uso concretos foram identificados. Esta seção fala especificamente sobre cada um deles para recomendar caminhos para desenvolvedores que publicam recursos XML que usam XSLT atualmente.
Feeds RSS e Atom
Em muitos feeds RSS ou Atom, o XSLT é usado para tornar os feeds XML brutos legíveis por humanos quando visualizados diretamente em um navegador. O principal caso de uso é que, quando um usuário clica acidentalmente no link do feed RSS de um site, em vez de colar esse link no leitor de RSS, ele recebe uma resposta HTML formatada que pode ser lida, em vez do XML bruto.
Há duas opções para esse caso de uso. A maneira "padrão" de fazer isso em HTML é adicionar <link rel="alternate" type="application/rss+xml"> a um site (baseado em HTML), em vez de adicionar um <a
href="something.xml"> explícito (visível para o usuário) em que os usuários podem clicar acidentalmente. Essa solução permite
que os leitores de RSS encontrem o feed se um usuário colar apenas o URL do site, mas também
permite que os usuários humanos vejam o conteúdo HTML normal sem se confundirem
com um link para um recurso XML. Isso também segue o paradigma normal da Web, em que
o HTML é para humanos e o XML é para máquinas. É claro que isso não resolve o
caso em que um usuário apenas "tem" um link RSS de algum lugar e o cola no
navegador da Web (em vez do leitor de RSS).
Quando essa solução não é desejada, o polyfill oferece outro caminho. Como mencionado
anteriormente, o feed XML RSS/Atom pode ser aumentado com uma linha, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>,
que vai manter o comportamento atual da transformação baseada em XSLT para HTML.
Isso não deve afetar a capacidade do leitor de RSS de continuar analisando o XML, já que
o <script> é um filho direto do elemento raiz.
Saída da API para dispositivos incorporados
Alguns dispositivos comerciais incorporados medem ou geram dados XML para
consumo por usuários na rede local. Alguns desses dispositivos fazem isso
gerando um único feed de dados XML que usa XSLT para transformá-lo em um
formato HTML legível por humanos. Isso permite que a API seja visualizada diretamente em um
navegador sem precisar de código adicional no dispositivo ou no navegador.
Como esse é um caso de uso muito específico do aplicativo, o formato da solução
pode variar. Para aplicativos em que o código-fonte do dispositivo incorporado pode ser atualizado, qualquer uma das opções descritas anteriormente (JSON, Polyfill) pode funcionar. No entanto,
muitos desses dispositivos são difíceis ou impossíveis de atualizar,
por vários motivos. Nesse caso, a
extensão
provavelmente é a melhor opção, já que permite que os navegadores do cliente continuem lendo
os dados exatamente da mesma maneira, sem modificar o dispositivo.
Modelos lentos para sites
Os desenvolvedores web às vezes usam XSLT no lado do cliente para aplicar marcação de apresentação à marcação semântica, funcionando como uma linguagem de modelagem lenta que é separada do ecossistema do JavaScript.
Há duas soluções para esse problema mais geral. Para um site atual criado dessa forma, a solução mais fácil é adicionar o polyfill para manter a funcionalidade atual. Ou talvez realizar a transformação XSLT no lado do servidor e exibir o HTML resultante para o cliente, em vez do XML bruto. A solução de longo prazo para essas propriedades seria migrar para um framework mais moderno baseado em JavaScript ou JSON.
Se você encontrar um problema específico no Chrome relacionado a essa descontinuação do XSLT, informe um bug aqui.
Como detectar o uso de XSLT
Em geral, recursos descontinuados, como o XSLT, podem ser detectados na base de código de algumas maneiras. Nesta seção, descrevemos duas delas.
API Reporting
A API Reporting é um mecanismo de relatórios genérico para aplicativos da Web usarem relatórios sobre vários recursos e condições da plataforma, incluindo descontinuações de recursos. Para configurá-lo para informar sobre a descontinuação do XSLT, use um snippet de código como este:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
Confira esse código em ação no CodePen.
Relatório de tecnologia legada empresarial
Para administradores de uma empresa, o Relatório de Tecnologia Legada pode ser usado para coletar automaticamente o uso de recursos descontinuados e informá-los de maneira fácil de usar. Consulte este artigo do Suporte do Google para mais informações sobre como ativar esse recurso.