Google did not unilaterally decide to kill XSLT

Scope of the Decision and Standards Process

• Multiple vendors (Chrome, Firefox, WebKit) are described as wanting to remove XSLT; it is not a solely Google-initiated move, though a Google-linked issue triggered the public reaction.
• Participants note that WHATWG issues are primarily coordination tools for spec editors, not community referendums, which helped fuel misunderstandings.
• Some stress that standards cannot force implementations: “the web is what engines ship and sites use.” If all engines drop a feature, the spec becomes moot.
• Others argue that decisions by a small set of vendors are effectively unilateral for “tech that affects billions,” and that there should be a clearer, formal public process and venue for feedback.

Resources, Power, and Responsibility

• One side: browser teams have limited budgets; maintaining a niche, complex, security-sensitive feature is a poor use of resources. Companies are entitled to allocate their money as they like.
• Other side: “we don’t have resources” is viewed as a political choice, especially for a company with vast overall wealth. With monopoly-like power comes a moral duty to preserve web stability.
• There’s a split between “Play Nice” (persuade vendors respectfully) vs “Fight the Power” (public shaming and resistance are ethically justified when powerful actors shape the web).

Backwards Compatibility vs Cleanup

• Some see removing underused features as essential hygiene, citing security risk and maintenance cost of XML/XSLT, with prior precedents (FTP, unload, mutation events, Flash, cookies).
• Others counter that XSLT is currently implemented and used; removing a baseline browser feature that can entirely break pages is qualitatively different and should have an extremely high bar.
• Several note that timeline matters: people running sites, factories, and legacy enterprise systems need years of warning and viable migration paths.

Technical Merits and Alternatives

• Supporters of XSLT value client-side XML→HTML templating, separation of data/presentation, and zero-build, low-JS workflows; some still use it for hobby sites, reporting, or glue systems.
• Critics call XSLT and XML “impossible to implement correctly,” attack-surface heavy, and rarely seen on today’s web outside niche/legacy cases.
• Proposed mitigations include WebAssembly polyfills (criticized as large and impractical unless bundled), proxies, or replacing XSLT with CSS/JS and new HTML features (e.g., includes/partials).
• There’s broader debate about whether new declarative features (HTML includes, partial updates) should become native, versus “just use a few lines of JS.”