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 overall sentiment of the Hacker News discussion is predominantly skeptical and disagreeing with the article's primary argument that XSLT deprecation is a malicious, anti-open-web political move by Google. While some acknowledge broader concerns about corporate control and the web's direction, the specific case of XSLT's removal is largely viewed as a practical, justified decision due to its obsolescence, complexity, security risks, and low usage, with support from multiple browser vendors.

In Agreement

• Google's actions, such as removing XSLT and pushing non-standard polyfills, mirror monopolistic behavior reminiscent of Internet Explorer 5.1, demonstrating an 'owner's' rather than a 'servant-oriented' mentality for the web.
• The deprecation of XSLT, alongside past removals like built-in RSS, undermines the ability of individuals to create simple web pages and consume content without relying on complex JavaScript or corporate platforms, thereby eroding the 'open web' and individual empowerment.
• Claims of security concerns for XSLT are disingenuous, as the proposed JavaScript polyfill suggests that sandboxed execution is feasible, implying that the real motives are not technical but strategic.
• Browser vendors, especially Google, exhibit inconsistent priorities by maintaining newer, niche hardware APIs with significantly less usage than XSLT, while deprecating XSLT, which suggests a political agenda rather than a genuine cost-benefit analysis.
• The removal of any feature, especially one with existing usage, breaks the implicit contract of backward compatibility that web developers expect, making it harder to rely on web standards for long-term content preservation.

Opposed

• XSLT is an obsolete, complex, and rarely used technology (often described as 'terrible' or 'ugly') whose removal is 'long overdue' due to its inherent complexity, security vulnerabilities, and significant maintenance burden.
• JavaScript and modern web frameworks provide superior, more secure, and easier-to-use alternatives for web templating and data transformation, making native XSLT support in browsers largely unnecessary.
• The decision to deprecate XSLT is not a Google-specific conspiracy but a collective, widely supported move by all major browser vendors (Mozilla, Apple, WHATWG) based on a rational cost-benefit analysis for browser maintenance and security.
• The decline of features like RSS was primarily driven by user preferences shifting towards social media and other content consumption models, rather than a deliberate suppression effort by browser vendors.
• The concept of an unwavering 'backward compatibility contract' for all web features is unrealistic; maintaining old, unused code incurs significant costs and security risks, and browser developers have agency in managing their software's complexity.
• Other legacy browser features like FTP and Gopher were also removed due to security concerns and lack of modern utility, indicating a natural evolutionary process of the web rather than a malicious political agenda targeted specifically at XSLT.