Chrome and Edge are removing XSLT: what breaks and what does not

Original Article ↗ Hacker News Discussion ↗

Chrome and Edge are deprecating built‑in XSLT support, prompting concern about breakage for XML-based sites, styled RSS/Atom feeds, and niche workflows that rely on client-side transformations. Proponents of removal argue that XSLT is rarely used, complex to maintain, and a nontrivial security and attack surface, especially given aging XML libraries, while others lament the loss of a powerful, declarative templating tool and symbol of the abandoned XML/XHTML vision for the web. Alternatives floated include server-side transforms, JavaScript or WebAssembly-based XSLT engines, or simpler CSS-based styling, though many see no true like-for-like replacement.

Scope of the change

  • Chrome is deprecating and removing built‑in XSLT; Edge, as a Chromium fork, is expected to follow.
  • Firefox currently still works but logs warnings and has an “intent to unship” XSLT as well.
  • Net effect: in‑browser XSLT goes away; server‑side XSLT remains unaffected.

Reasons given for removal

  • Legacy, rarely used feature with a large and complex attack surface.
  • Underlying XML libraries are old, under‑maintained, and have a history of vulnerabilities.
  • Maintaining this code for billions of users is considered expensive.
  • Some see LLMs as making maintenance cheaper; others argue they also lower the cost of finding exploits and don’t eliminate security/maintenance costs.

Skepticism and criticism

  • Some view this as browser‑monoculture behavior: vendors “just take down stuff because they don’t bother.”
  • A few frame it as a pattern similar to Flash’s demise: create a security narrative to justify removal of inconvenient tech.
  • Others respond that almost no one uses or maintains XSLT anymore and it’s unreasonable to expect ongoing support.

Impact and breakage

  • XML+XSLT‑based UIs (e.g., some IIS reports, TEI/XML readers, styled RSS/Atom feeds, XSLT‑based blogs) will break or degrade in Chromium‑based browsers.
  • Chrome already surfaces a prominent warning on XSLT use.
  • Government and regulatory sites using XSLT are noted as at risk (linked issues).

Alternatives and migration paths

  • Do the XSLT transformation on the server and serve plain HTML.
  • Use JS or WebAssembly‑based XSLT processors client‑side (though wrapper code and examples are still immature).
  • Style XML/RSS directly with CSS, accepting limitations.
  • Replace XSLT templating with JS‑based techniques (e.g., document.currentScript + DOM APIs) or other templating engines.

Broader XML/XHTML/XSLT debate

  • Some mourn a lost “XML/XHTML future” with schemas, client‑side templating, and cleaner modularity.
  • Others argue XHTML/XML/XSLT had poor tooling, steep learning curves, verbose syntax, and never gained mass adoption.
  • Strict XML/XHTML vs forgiving HTML is heavily debated; strictness seen both as a benefit (clear errors) and a barrier (brittle content).