XSLT RIP

Retro design & implementation details

  • Many enjoy the intentionally gaudy 90s look (Comic Sans, animated GIFs, custom cursor); others say it’s a caricature of “retro” and not how most serious 90s sites looked.
  • Several point out that the page is a real XML document with an xml-stylesheet PI, and that it’s a clever “feature test”: if your browser supports XSLT you see the styled page; otherwise you only see the bare XML text.
  • Text-mode browsers just show the “XSLT was killed by Google” text, which some compare to “This site requires JavaScript”.

Browser support & security rationale

  • Chrome is deprecating XSLT 1.0 (libxslt-based) citing security issues in old C/C++ code and very low usage.
  • FreeBSD advisories and conference talks are cited as evidence of long‑lived exploitable bugs in XSLT engines.
  • Firefox and Apple are described as broadly agreeing with removal in standards discussions, though Chrome is seen as pushing hardest and acting fastest.

Arguments for removal

  • XSLT in the browser is described as niche, hard to debug, and historically buggy; many developers say they hated writing it and always preferred JavaScript + JSON.
  • Maintaining legacy, little‑used features is framed as a cost that hurts smaller browser projects and new engines.
  • Some argue XSLT belongs on the server or in specialized tools, and that existing JavaScript/WASM XSLT libraries are sufficient when needed.

Arguments against removal

  • Critics say this weakens the “open web” by dropping a W3C standard with no native replacement, unlike Flash/Java applets which were proprietary plugins.
  • XSLT is still used for: human‑friendly RSS/Atom views, government/legal documents, hospital record rendering, enterprise XML stacks, EPUB/SVG/DocBook, etc.
  • Static‑site and hobby authors rely on client‑side XSLT to turn XML into HTML without servers or build pipelines; removal pushes them toward JS or dynamic hosting.
  • Several argue Google could afford to fund maintenance, or ship a sandboxed JS/WASM polyfill by default, instead of blaming an underfunded C library.

RSS, UX, and alternatives

  • One camp: RSS is for aggregators; styling feeds in‑browser is nonessential and can be replaced by server‑side transforms, content negotiation, or CSS.
  • Other camp: styled feeds are a key “on‑ramp” for non‑RSS users; XSLT let a single XML file serve both machines and humans, especially on cheap static hosting.

Power dynamics & governance

  • Many see this as another example of Chrome’s dominance letting Google “kill” web features unilaterally, alongside complaints about AMP, ad tech, uBlock changes, and Android policies.
  • Others counter that this is a rare, obscure feature, that all major engines want gone, and that energy would be better spent fighting real bloat and new experimental APIs.