Proposta para remover menções ao XSLT da especificação HTML

 (github.com/whatwg)
2 pontos por GN⁺ 2025-08-20 | 1 comentários | Compartilhar no WhatsApp
  • Foi proposto um Pull Request para remover menções relacionadas a XSLT do documento padrão do HTML
  • O autor da proposta explicou que há bugs de implementação relatados nos principais navegadores, como Chrome, Firefox e Safari, e que questões de teste e documentação também estão em andamento
  • Opiniões contrárias apontam problemas de compatibilidade com sites existentes e problemas de legibilidade em que documentos XML podem quebrar com a remoção de <?xml-stylesheet?>
  • Alguns desenvolvedores enfatizam que o XSLT ainda é usado em documentos governamentais, RSS e ambientes embarcados
  • Também foi levantada a preocupação de que decisões centradas em grandes fabricantes de navegadores possam levar à redução da abertura da web e de sua diversidade histórica

Visão geral do Pull Request

  • Título do PR: Remove mentions of XSLT from the html spec
  • Autor da proposta: mfreed7
  • Destino: whatwg/html:main
  • Issue relacionada: #11523
  • Há relatos de bugs de implementação relacionados em Chromium, Gecko e WebKit
  • Materiais relacionados, como a documentação da MDN e o HTML AAM, também devem ser atualizados

Principais objeções

gucci-on-fleek (2025-08-15)

  • Defende que é preciso considerar estatísticas de uso e a escala dos sites
    • Sites grandes podem ser atualizados, mas sites pequenos/pessoais muitas vezes ficam décadas sem manutenção, gerando preocupação com quebra permanente de compatibilidade
  • Remover XSLTProcessor() limitaria apenas uma funcionalidade de JS, mas remover <?xml-stylesheet?> causaria o problema de documentos XML simplesmente não serem exibidos
  • Recursos antigos do HTML (<font>, <align>, <xmp>) ainda funcionam, mas desta vez, segundo a crítica, trata-se de uma mudança sem precedentes que quebra o próprio documento
  • Destaca-se o risco de bloquear o acesso a materiais importantes, como arquivos antigos e sites universitários

nomis (2025-08-18)

jonsterling (2025-08-18)

  • Critica a realidade em que fabricantes de navegadores definem a plataforma web de forma monopolizada
  • Afirma que o XSLT ainda contribui para usos diversos e criativos da web, e que sua remoção pode levar ao enfraquecimento da Open Web
  • Enfatiza o princípio de que “a web é de todos nós”, defendendo a necessidade de respeitar sua história e diversidade

Apoio e medidas posteriores

  • domenic (2025-08-19): reagiu positivamente e apontou a necessidade de atualizar também as menções a XSLT na especificação DOM
  • mfreed7 (2025-08-19): respondeu que enviará um PR separado também para a especificação DOM

Resumo

  • A remoção do XSLT é uma mudança proposta como parte dos esforços de simplificação e modernização dos navegadores
  • No entanto, os opositores temem danos à compatibilidade de documentos existentes, à acessibilidade de dados governamentais/acadêmicos e à diversidade da web aberta
  • A discussão atual vai além de uma simples escolha técnica e se estende a um debate filosófico sobre quem deve ter o poder de decidir os padrões da web

Leituras relacionadas

1 comentários

 
GN⁺ 2025-08-20
Opiniões no Hacker News

  • Há alguns pontos dignos de nota

    • Esta decisão não é uma ação unilateral do Chrome, e é possível confirmar no rastreamento da issue e nos registros das reuniões de padronização relacionadas que representantes de todos os principais navegadores demonstraram apoio

    • A pauta recente também foi proposta por um engenheiro da Mozilla

    • O envio do PR não significa que ele será mesclado imediatamente, e ainda restam várias tarefas não resolvidas

    • Mas, como vários fabricantes de navegadores concordam, há grande chance de ele ser mesclado

    • A issue que discute se o XSLT deve ser removido da plataforma web não é para coletar opiniões da comunidade, mas sim uma issue de discussão para os mantenedores da especificação HTML

    • Essa issue foi aberta por um engenheiro do Chrome, mas o fato importante é que engenheiros da Mozilla levantaram esse tema várias vezes em reuniões e já havia consenso entre os vendors

    • Já foi encontrada uma vulnerabilidade de segurança grave

    • O mantenedor principal do libxslt também renunciou diretamente

    • Removeram a palavra Chrome do título

    • O título enviado originalmente era "Chrome intends to remove XSLT from the HTML spec"

    • Segundo os dados de telemetria do Chrome, quase não há sites que realmente usem XSLT

    • Pelo menos os dados indicam que a proposta não teria grande impacto na web como um todo

    • Sou um desenvolvedor que trabalhou no passado na Mozilla e no Google (equipe do Chrome)

    • Entendo que Chrome/Blink, Safari/Webkit e Firefox/Gecko apoiam a remoção do XSLT, mas dois projetos têm falta de recursos, e um deles tem forte tendência a empurrar novos recursos de forma agressiva

    • Também há motivos para desenvolvedores do Safari e do Firefox verem essa mudança com bons olhos

    • O importante não é se "pessoas com autoridade acham que é uma boa ideia", mas sim se "essa ideia terá impacto negativo na plataforma web e em bilhões de usuários"

    • Mesmo que só 0,1% de bilhões de pessoas dependam disso, ainda é uma escala significativa

    • Se ninguém usa, não haveria motivo para existir um polyfill

    • Não é desejável transformar a adição de novas funcionalidades em um jogo de soma zero no qual seja obrigatório remover recursos existentes

    • O Google está escolhendo deliberadamente não oferecer suporte a XSLT, apesar de ter capital e equipe suficientes

    • Muitas vezes já houve casos em que algo avançou imediatamente porque vários vendors concordaram

    • Foi assim com a remoção de confirm/prompt, mas no fim ficou adiada por tempo indeterminado

    • Existe um documento oficial do Google sobre o processo de remoção de funcionalidades afiliadas
      Google feature removal doc

    • O "apoio isolado dos vendors" não examinou adequadamente o uso real

  • Pelas duas threads que li, o Google pediu feedback, mas quase todo o feedback foi "não façam isso"

    • Mesmo assim, o Google respondeu algo como "obrigado pela opinião, mas vamos fazer mesmo assim!"

    • Se a questão fosse segurança, havia várias alternativas, como apoiar o open source, trocar por uma biblioteca mais segura ou manter isso dentro de um sandbox JS, mas a maioria foi ignorada

    • Também houve pedidos contínuos por suporte a versões mais recentes, como XSLT 3.0, mas eles não foram atendidos

    • Embora o XSLT seja uma tecnologia que apoia a web aberta, o Google vem reduzindo o suporte e deixando isso de lado há 10 anos, enquanto tenta removê-lo com base na queda de participação

    • Agora que o XSLT está voltando a ganhar popularidade, fica a sensação de que querem matá-lo antes que apareça um concorrente aberto

    • Issue relacionada

    • Quanto à afirmação de que muito do feedback foi "não façam isso", aquela thread foi bloqueada cedo por comentários maliciosos, ataques pessoais etc.

    • Opiniões como "isso é uma boa ideia" normalmente não aparecem muito, então pode parecer que só há oposição

    • Todo mundo se comportou de forma extrema e a discussão acabou sendo encerrada, algo que foi provocado pelos próprios participantes

    • Se os comentários de "por favor, não façam isso" não vierem de usuários reais ou não conseguirem explicar por que isso é necessário, é razoável que a equipe de desenvolvimento os ignore

    • Um pedido de feedback não é simplesmente uma votação de sim ou não

    • Seria bom se fosse possível levar o suporte a XSLT 3.0 para um sandbox JS/wasm

    • Haveria alguma perda de desempenho, mas daria para aproveitar o melhor dos dois lados

    • O XML, por características como esquemas versionados e namespaces, é relativamente fácil de integrar

    • Ao contrário de frameworks JS como Angular, ele permite contratos de dados altamente confiáveis

    • Graças à maturidade da família XML, há muitas ferramentas especializadas, então na prática nem é preciso lidar manualmente com XML/XSD como texto

    • O Google costuma anunciar antecipadamente o que vai acontecer na web em forma de "pergunta"

  • Apresentação de threads relacionadas anteriores

  • Fico em dúvida se o navegador realmente precisa ter suporte embutido para um mecanismo de templates específico (XSLT)

    • Não é um mecanismo de texto como o Jinja, e também pode ser reimplementado em JS/wasm

    • Hoje os navegadores estão pesados demais, e criar novos engines é difícil

    • Eu gostaria que houvesse apenas um padrão mais simples para "navegadores mínimos" (tags básicas, layout etc.)

    • WebAudio, Canvas e afins também poderiam ser implementados como módulos wasm (e assim ainda evitar fingerprinting)

    • XSLT é uma "especificação" para um mecanismo de templates, não um engine específico, e existem várias implementações

    • A Mozilla usa transformiix em vez de libxslt

    • Jinja lida apenas com texto simples, enquanto XSLT opera no nível de nós e é muito superior

    • Transformações em JS são muito mais lentas do que transformações nativas em XSLT, e também é mais difícil fazer cache do resultado

    • Eu até entendo a visão de que o XSLT é ultrapassado, mas o usei muito bem como arma secreta de desempenho nos últimos 20 anos

    • No fim, há grande chance de o Google tentar encobrir o problema com alguma alternativa como AMP

    • Os navegadores são pesados por culpa do Google

    • XSLT é uma linguagem (spec), não um engine

    • Mudar a implementação para JS/wasm é uma questão de implementação interna, e não o que acontece quando se remove a linguagem da plataforma web

    • Áudio e canvas são funcionalidades fundamentais de I/O do navegador; movê-las para wasm causaria sérios problemas de desempenho e compatibilidade

    • Talvez parte do áudio pudesse ser levada para um blob wasm, mas mover tudo seria difícil

    • Contexto de canvas e WebGL dependem de integração direta com a GPU, então não dá para realizá-los em wasm

    • No fim, essas funcionalidades já são praticamente APIs primitivas básicas, então são uma área inegociável

    • Também se discutiu a ideia de empacotar código XSLT antigo em wasm para manter compatibilidade sem quebrar sites antigos

    • De fato isso foi analisado internamente, mas decidiu-se não seguir por esse caminho

    • Acho que funcionalidades muito pouco usadas e distantes do núcleo da web podem ser candidatas à remoção

    • Mas não concordo em usar vulnerabilidades de segurança como justificativa

    • Sem sequer verificar se existe um pacote memory-safe, isso perde força como argumento

    • Há quem diga que o uso real está na faixa de 0,001%

  • Quebrar a promessa básica da especificação HTML é algo extremamente sério

    • É até surpreendente que a discussão não trate isso em profundidade

    • HTML era a promessa de "isto é HTML. Você pode confiar", mas agora vira "isto é HTML por enquanto, sem garantia de que continue sendo no futuro"

    • Se a lógica para remover XSLT vale, então outras tecnologias antigas também poderão continuar sendo cortadas

    • No fim, é uma proposta para cortar a "long tail" da web

    • Também é preciso pensar que várias tecnologias web adicionadas mais tarde podem se tornar outra long tail e gerar ainda mais remoções no futuro

    • Em relação ao suporte a mídias e softwares antigos, acredito que em algum momento chega a hora de resolver isso com portabilidade, emulação, arquivamento etc.

    • É preciso equilíbrio entre dar tempo e ferramentas suficientes para adaptação e evitar o acúmulo gradual de complexidade

    • Ao ver o trecho removido no PR, não parece haver uma exigência explícita de que HTML tenha suporte a XSLT

    • A reação parece estar mais ligada ao problema de suporte nos navegadores

    • O próprio PR é surpreendentemente curto

    • Como o WHATWG define o HTML como um "Living Standard", na prática ele já não funciona mais como um padrão de implementação, e sim como um meio de compartilhar o estado atual do que os vendors de navegadores estão fazendo

    • Por isso também deixaram de usar designações de versão como HTML5, passando a usar apenas "HTML"

    • Living Standard FAQ

    • HTML standard FAQ

    • Ironicamente, quem mais empurrou enormes quantidades de funcionalidades para dentro das specs de HTML/CSS/navegadores foi justamente o Google

    • Se o Google tivesse defendido de forma consistente que "navegadores devem ser leves e as coisas estranhas devem ficar em bibliotecas JS", esta medida seria até compreensível, mas não foi isso que aconteceu

  • Desde a remoção do suporte a FTP, o destino do XSL já era previsível

    • Os navegadores tendem a priorizar acima de tudo a redução da superfície de ataque

    • Acho que os próximos candidatos à remoção podem ser atributos de animação SVG SMIL, MathML e outras funcionalidades ligadas a XML

    • Thread relacionada

    • O SMIL permite controlar animações sequenciais com base no momento de início e término de animações específicas, algo que as animações CSS ainda não cobrem bem

    • Em CSS, fora usar cálculos, não há muito como fazer isso

    • O Chromium também já demonstrou intenção de remover o SMIL, mas era cedo demais porque o CSS não era suficiente

    • Como consequência, vários avisos e documentos sobre SMIL ficaram abandonados sem atualização

    • Eu questionaria se reduzir a superfície de ataque é de fato algo bom ou ruim

    • Engenheiros e usuários comuns têm prioridades diferentes

    • Fico curioso sobre quando exatamente ocorreu a remoção do FTP

    • Pelo que sei, ainda dá para acessar ftp:// pela barra de endereços

  • As implementações de XSLT no Blink e no WebKit são muito ineficientes

  • Embora esta decisão seja lamentável, é ainda mais triste que não tenham investido em uma integração mais moderna do XSLT

    • Era desconfortável de usar, mas, se tivesse evoluído um pouco mais dentro do navegador, talvez pudesse ter se tornado um concorrente à altura de frameworks como React

    • O XML, sem a complexidade corporativa das grandes empresas, era uma tecnologia realmente poderosa e elegante como padrão

    • Eu gostava muito de usar XSLT para transformar diretamente xml/dados pequenos e simples em html

    • É uma pena pensar que, com apenas alguns recursos adicionais, como destacar de forma diferente apenas o item selecionado, isso poderia ter sido útil até para documentos estáticos

  • Dizem que o @whatwg bloqueou a issue para apenas colaboradores, alegando que a discussão "esquentou demais"

    • À primeira vista ela parecia bem razoável e calma, então dá a impressão de que o critério para "acalorado" talvez mude dependendo de quão favorável se é a um vendor específico

    • A expressão "esquentou demais" muitas vezes é interpretada como "não queremos lidar com opiniões contrárias"

    • Em outras comunidades, como o Reddit, acontece a mesma coisa

    • Na prática, o único comentário que restou ali embaixo foi de um desenvolvedor do Google Chrome dizendo algo como "bom trabalho"

    • Fica um pouco constrangedor de ver

    • Mencionam casos em que a issue tracker foi inundada com xingamentos, teorias da conspiração e mensagens políticas

    • Desse jeito, a discussão produtiva se torna impossível, e os mantenedores do repositório acabam tendo de bloquear rapidamente o debate

    • Ouvi dizer que a decisão de travar a discussão no repositório foi, na verdade, tomada por um funcionário da Apple

    • Mas as pessoas estariam atribuindo a responsabilidade ao funcionário do Google que abriu a issue

    • O Google recentemente abriu uma discussão pública em nome de ouvir a comunidade, mas depois está tentando impor a mudança ignorando todas as opiniões

    • Issue relacionada

  • É preciso refletir de forma mais ampla sobre elementos antigos da web

    • No meu caso, há muito valor em continuar tendo páginas antigas funcionando corretamente

    • Graças à compatibilidade preservada por HTML/JS, até páginas com décadas de idade continuam funcionando normalmente se você apenas adicionar um certificado TLS

    • Mas também não é possível manter para sempre suporte a toda tecnologia legada

    • O Flash acabou migrando para uma experiência via emulador (Ruffle), para reviver jogos e sites nostálgicos

    • No longo prazo, usar navegadores dedicados ou emuladores especializados em renderização antiga também pode ser uma alternativa

    • Já surgiu até uma extensão polyfill de XSLT para isso

    • O Chrome não quer distribuí-la oficialmente nem fazer sua manutenção

    • É uma situação muito parecida com a do Ruffle