A morte do XSLT — Google vai encerrar o suporte a XSLT

 (xslt.rip)
1 pontos por GN⁺ 2025-11-11 | 2 comentários | Compartilhar no WhatsApp
  • O Google anunciou oficialmente o plano de encerrar completamente o suporte a XSLT até 2027
  • XSLT é uma linguagem para transformar documentos XML em outras formas de XML, ainda usada em vários sites governamentais
  • No passado, o Google já tentou encerrar o suporte a XSLT em 2013, e esta é a segunda tentativa
  • Mozilla e Apple também manifestaram intenção de participar da remoção do XSLT, e a relação financeira com o Google é mencionada
  • A medida é vista como uma mudança tecnológica importante que pode afetar os padrões da web e a acessibilidade de conteúdo

Anúncio do fim do suporte a XSLT pelo Google

  • Em 24 de outubro de 2025, o Google publicou no fórum de desenvolvedores do Chromium o documento “Intent to Deprecate and Remove: Deprecate and remove XSLT”
    • Com isso, a funcionalidade de XSLT deverá ser completamente removida até 2027
  • O Google já havia tentado remover o XSLT em julho de 2013
    • A tentativa da época foi interrompida, mas agora foi retomada 12 anos depois com este novo anúncio

Histórico de descontinuação de tecnologias pelo Google

  • Até agora, o Google é conhecido por encerrar cerca de 300 tecnologias
    • Um exemplo famoso é o Google Reader, cujo encerramento foi anunciado em 13 de março de 2013
  • Em breve, o XSLT deverá ser adicionado à lista do ‘Killed by Google’
  • O texto usa a expressão “o Google odeia XML e RSS” e enfatiza a relação entre RSS e XSLT

Alegações sobre XML e RSS

  • RSS é uma tecnologia usada para distribuição de notícias, e o texto menciona a possibilidade de controle das notícias ao removê-la
  • XSLT é uma tecnologia usada em vários sites governamentais, e aponta-se que a medida do Google também pode afetar tecnologias web ligadas à legislação
  • O texto apresenta uma visão crítica de que “o Google fortalece seu controle sobre a web ao remover XML e RSS”

Posição de outros navegadores

  • A Mozilla afirmou que a remoção do XSLT “pode quebrar conteúdo existente da web (break existing web content)”
  • A Apple manifestou a posição de que gostaria de participar antes do cronograma de 2027 do Google (participate sooner)
  • O texto cita que o Google pagou à Mozilla cerca de US$ 420 milhões por ano e à Apple US$ 20 bilhões em um ano
    • O cálculo apresentado indica um total de cerca de US$ 244,2 bilhões pagos às duas empresas nos últimos 10 anos

Apelo pela preservação do XSLT

  • O autor enfatiza a mensagem de “impedir que o Google mate o XSLT”
  • Também inclui um chamado à ação: “adicione XSLT aos seus sites e blogs”
  • O texto termina com o slogan “Keep XSLT alive!”, fazendo um apelo à participação dos usuários e à preservação da tecnologia

Leituras relacionadas

2 comentários

 
t7vonn 2025-11-12

Vamos parar de mandar isso.
 
GN⁺ 2025-11-11
Comentários do Hacker News

  • Eu esperava que o site fosse realmente um documento XML e, felizmente, era mesmo
    Se você verificar com o comando curl https://xslt.rip/, verá que dentro da tag <html> há a frase “If you're reading this, XSLT was killed by Google.”

    • Essa é uma forma inteligente de distinguir se o navegador oferece suporte a XSLT
      O conteúdo real está em index.xsl, e o autor é um designer de frontend que também mantém um belo site pessoal chamado dbushell.com
      Ambos os sites têm uma sensibilidade bastante pessoal
    • Para mim, XSLT parece uma tecnologia que fez a complexidade da web explodir e acabou deixando apenas dois navegadores de pé
      O design do site lembra a web dos anos 90, o que é estranhamente engraçado
    • Se você acessar com um navegador de texto (como Lynx), só verá essa frase, o que passa uma sensação parecida com quando aparece em <noscript> a mensagem “este site requer JavaScript”
      Agora fiquei curioso se ainda existe algum navegador além do Google que implemente XSLT

  • Sou fortemente contra remover o suporte a XSLT dos navegadores
    Eu uso tanto XSLTProcessor em JavaScript quanto <?xml-stylesheet …?> no meu site pessoal, e também deixei minha opinião na thread do GitHub
    Mas acho que este site usa um tom um pouco exagerado. Acredito que os motivos de segurança e manutenção do Google sejam sinceros, mas considero a direção errada
    Esse tipo de página pode acabar mais irritando os tomadores de decisão do que convencendo-os

    • Quem usa um recurso desses provavelmente é uma equipe de elite muito pequena
    • Se a transformação XSLT for feita no servidor, dá para usar ferramentas modernas e isso funciona em todos os navegadores
    • O exagero do site parece ser humor intencional
    • Não dá para convencer tomadores de decisão com uma única página da web. O objetivo dela é simplesmente aumentar a conscientização sobre o problema
    • Considerando que o libxslt quase não recebe manutenção e tem muitas vulnerabilidades de segurança, acho justificável removê-lo
      Se alguém realmente quisesse salvar o XSLT, o melhor caminho teria sido criar uma nova implementação em Rust

  • Talvez eu esteja na minoria, mas acho lamentável a realidade de ver o XSLT parando
    Há 25 anos, criar inúmeras bibliotecas incompletas para substituir o ecossistema XML+XPath+XSLT foi um desperdício de talento
    Reconheço os excessos do SOAP e do XML Schema, mas a abordagem inicial do JSON com eval() também não era boa engenharia
    No fim, poderíamos ter construído um sistema XML melhor, mas é uma pena que, fascinados pela novidade, tenhamos abandonado as vantagens que já existiam

    • Ainda quase não existem bons parsers de XML, mas há muitos parsers de JSON
      Em Ruby, Python, Java etc., fazer parsing de XML sempre foi doloroso, enquanto JSON era muito mais simples e estável
    • A especificação do JSON termina em duas páginas, enquanto a do XML é um livro inteiro. Só isso já mostra a diferença de peso
    • Já usei XSLT no passado e realmente detestei profundamente
      Era complexo a ponto de exigir um especialista dedicado, e isso por si só parecia desperdício
    • Ainda assim, havia usos muito legais, como renderizar arquivos RSS diretamente no navegador
      É uma pena ver desaparecerem ideias da web semântica dos anos 2010

  • Quase não uso XSLT, mas me irrita o fato de o Google agir como se fosse “a própria web”
    O mesmo vale para a tentativa de eliminar o uBlock Origin, e também não gosto de como navegadores com IA mostram a realidade de forma distorcida
    Não quero viver em um mundo em que governos ou empresas atuem como intermediários controlando a informação
    Também acho que a qualidade da busca do Google já vem piorando de propósito há uns 5 anos

    • Penso o mesmo. Não me importo com XSLT, mas há um grande cansaço nessa sensação de que, se o Google decidir acabar com o HTML, quem poderia impedi-lo?
    • O preocupante é que hoje, na prática, existem apenas três motores de navegador
    • O Google deveria separar Search, Android, Chrome e AdSense
      Com o monopólio da publicidade, a remoção de adblockers e as restrições à instalação de apps, ele dominou o ecossistema da web
      Ainda assim, o design deste site é realmente bonito e tem uma forte estética retrô
    • Então qual seria o modelo alternativo?
      Mesmo dentro do Google, havia muitas decisões do tipo “não queremos ser nós a cuidar disso, mas quem mais poderia?”
      Assim como o OpenGL perdeu espaço para o DirectX após o fracasso do modelo de consórcio, há a lição de que a abertura de um padrão, por si só, não basta para proteger seu mercado
      Os padrões de navegador correm um risco parecido. No fim, o importante é quem consegue fazer sua voz ser ouvida

  • Como os navegadores já são complexos demais, concordo em parte com a decisão de remover o XSLT
    Pessoalmente nunca usei XSLT, e também não sinto que a relação com RSS seja tão forte assim

  • Mesmo que o Google curasse o câncer amanhã, alguém ainda diria “o Google matou o câncer”
    É improvável que fabricantes pequenos de navegadores queiram continuar fazendo manutenção em código XSLT antigo, e navegadores novos também provavelmente não planejam adicioná-lo
    Acho que foi uma decisão bem organizada

    • Mas navegadores pequenos já costumam implementar apenas os recursos de que precisam
      Nesse caso, gostaria de saber exatamente quais empresas apoiam essa decisão
    • Quando você diz “navegadores pequenos”, de quais está falando exatamente?

  • Este site parece uma espécie de teste de Rorschach
    Ao mesmo tempo, ele contém tanto a crítica de que “o Google matou o XSLT” quanto a sátira de que “insistir em XSLT em 2025 é ridículo”
    A frase “Tell your friends and family about XSLT! Add it to your website before it’s too late!” mostra isso muito bem

    • É claramente uma intenção de satirizar o exagero
    • Mas eu realmente uso XSLT por causa de feeds Atom
      Em um site estático, XSLT é a única forma de renderizar RSS de maneira apresentável
      Mudanças assim tiram ainda mais a autonomia da web pessoal e empurram tudo para o modelo centrado em grandes webapps

  • Parece o fim de uma era
    Antigamente, ao estudar tutoriais de XSLT, eu achava fascinante fazer documentos XML parecerem “vivos”
    Ainda hoje uso isso para estilizar meu feed RSS
    Os links do anúncio relacionado são o post no fórum do Chromium e a documentação para desenvolvedores do Chrome
    Entendo que a carga de manutenção é grande, mas dá a sensação de que mais um pequeno prazer da web está desaparecendo

  • O Google já monopoliza quase tudo
    Como no caso do Android (link relacionado), agora é o Google quem decide o que é permitido e proibido
    Por isso, seria bom criar um site de campanha como keepandroidopen.org, algo como keepXSLTAlive.tld
    Ou talvez refinar um pouco a interface do xslt.rip para dar um ar maior de resistência

    • Mas, mesmo que a crítica ao Google esteja correta, isso não significa que o XSLT deva continuar sendo mantido
      A tecnologia deve ser avaliada por seu próprio valor

  • Esta página é realmente incrível
    Deu até vontade de fazer uma página HTML ao estilo dos anos 90 usando tags <iframe>, <blink>, <marquee> e <table>

    • Brincadeira, mas agora blink e marquee precisam ser renderizados com Canvas
      Não, pensando bem, Canvas também já é antigo, então tem que ser com WebGPU
    • Uma faixa de “em construção” é indispensável
    • Recentemente precisei extrair dados de uma página composta só por tabelas, e era um verdadeiro inferno de tabelas aninhadas