Do Not Comply: Resisting Google’s XSLT Deprecation and the Corporate Capture of the Web

The author contends Google’s plan to remove in-browser XSLT and push a non-shipped polyfill is a deliberate tactic to undermine XML/RSS and centralize control. This aligns with a decade-long trend of corporate capture, removal of plugin escape hatches, DRM standardization, and weakened extensions that erode user agency. They call on developers to resist, keep using XSLT/RSS/JPEG XL, and treat failures as browser defects.

Key Points

Google’s XSLT deprecation and refusal to ship the polyfill by default either proves the polyfill is inadequate or signals an intent to suppress XSLT, shifting costs and risk onto developers.
This move fits a broader pattern of corporate capture (WHATWG direction, EME/DRM, Manifest V3, Mozilla’s RSS removal) that turns the web into a controlled app platform and surveillance tool rather than a user agent for documents.
The removal of plugin APIs (NPAPI/PPAPI) destroyed the web’s escape hatch for integrating new protocols and formats, slowing innovation and entrenching gatekeepers.
Alternatives exist (Pale Moon, Waterfox, Gemini), but engine dependence and ecosystem polish limit them; a modular, plugin-based browser could have enabled open evolution, yet is unlikely under current power structures.
Call to action: do not comply with the polyfill strategy, continue using XSLT/RSS/JPEG XL, and file breakage as browser bugs to pressure vendors to restore support.

Sentiment

The community is sharply divided. While there is broad sympathy for concerns about corporate control of the web and Google's outsized influence, a significant faction — including technically authoritative voices like the ex-libxslt maintainer — considers XSLT specifically to be the wrong hill to die on. The pragmatists argue this is a rational cost-benefit decision; the idealists see it as a precedent-setting violation of the web's social contract. Neither side dominates, though the pragmatic camp appears to have a slight edge in upvoted comments.

In Agreement

XSLT deprecation is symptomatic of browser vendors prioritizing their own convenience over users and content creators, violating the W3C's "priority of constituencies" principle
The security justification for removal is bad faith because browser vendors could ship an existing polyfill inside the browser's sandbox, achieving identical security without breaking existing websites
Removing a web standard that government sites like Congress.gov and weather.gov rely on, with only a one-year migration window, shows insufficient regard for the web's role as a public resource
WHATWG has become a corporate-captured body where three browser vendors effectively decide what the web is, sidelining the broader community of users and developers
Mozilla's alignment with Google on this decision reflects its financial dependence on Google's search deal, making the "all vendors agree" argument less meaningful than it appears
Breaking backwards compatibility, even for rarely-used features, undermines the web platform's implicit promise that standards-compliant content will continue to work indefinitely

Opposed

All major browser vendors (Google, Mozilla, Apple) unanimously agree on removing XSLT — this isn't a Google-only decision, and blaming only Google is ideologically driven rather than factual
The ex-maintainer of libxslt himself says removal was "long overdue," undermining claims that this is a corporate conspiracy against an important technology
XSLT has been effectively dead for years — no browser ever implemented XSLT 2.0 or 3.0, showing that even before deprecation no one cared enough to advance it
Maintaining XSLT has real costs in security vulnerabilities, maintenance burden, and attack surface that sandboxing doesn't fully eliminate
The "open web" doesn't mean browsers must support every feature forever — technologies like Flash, SSLv2, FTP, and gopher have all been removed without killing openness
Polyfills, server-side rendering, and WebAssembly provide adequate migration paths for the tiny number of sites still using browser-side XSLT
People are using XSLT as a symbol to criticize Google rather than engaging with the actual engineering trade-offs of maintaining a rarely-used feature