XSLT removal will break multiple government and regulatory sites

Original Article ↗ Hacker News Discussion ↗

Perceived impact and real-world usage

  • One side argues XSLT-in-browser is barely used; cited examples all have prominent HTML equivalents, so removal won’t meaningfully harm users.
  • Others counter that certain government/regulatory and personal sites rely on XML+XSLT specifically to make machine-targeted data human-readable at the same URL (e.g., laws, feeds, IoT/admin UIs).
  • Some worry especially about “silent” breakage where XML pages suddenly become “robot barf” again.

Metrics, telemetry, and “how much is enough?”

  • Pro-removal commenters lean on Chrome usage stats showing very low XML/XSLT page loads compared with text or PDF.
  • Critics say these metrics are biased (enterprise users, technical users, telemetry-off users) and too crude (page loads ≠ importance). They propose survey-like methods and weighting by user groups, but are challenged for lacking counter-data.

Security, maintenance cost, and standards simplification

  • XSLT engines are old, C-based, and have accumulated serious, long-lived vulnerabilities; keeping them is seen as ongoing security and maintenance “tax” for a tiny audience.
  • Others note the same vendors are happy to add complex, risky APIs (WebUSB, WebSerial, etc.), so “security/complexity” feels selectively applied.
  • Some argue browsers should have modernized to newer XSLT versions instead of letting implementations rot, then declaring them too painful to maintain.

Alternatives: server-side, polyfills, and extensions

  • Suggested workarounds: server-side transforms, JS/WASM polyfills, moving functionality to extensions, or just serving HTML instead of XML.
  • Pushback: automatic application of xml-stylesheet on bare XML URLs can’t be replicated purely with a client-side polyfill unless browsers add new hooks.
  • A WASM-based polyfill and a PR to allow script tags in XML are mentioned as partial mitigations.

XSLT’s unique value: format reuse and declarative web

  • Supporters highlight XML+XSLT as a clean separation of data and presentation, with one canonical XML source serving both machines and humans.
  • Use cases cited: RSS/Atom feeds with explanations, admin tools, low-power/IoT devices offloading rendering to the browser.
  • There’s broader frustration that browsers lack good, standardized, low-JS ways to build interactive, data-driven pages (XForms/XPath-like ideas).

Governance, process, and trust

  • Some see this as routine: deprecations can take a decade; removal from spec != immediate engine removal; precedents include applet and mutation events.
  • Others see inconsistency with the “never break the web” ethos and suspect commercial or anti-competitive motives from dominant browser vendors.