Thursday, August 21, 2025

Removing XSLT From the Web Platform

XSLT v1.0, which all browsers adhere to, was standardized in 1999. In the meantime, XSLT has evolved to v2.0 and v3.0, adding features, and growing apart from the old version frozen into browsers. This lack of advancement, coupled with the rise of JavaScript libraries and frameworks that offer more flexible and powerful DOM manipulation, has led to a significant decline in the use of client-side XSLT. Its role within the web browser has been largely superseded by JavaScript-based technologies such as JSON+React. The underlying libraries that browsers use to process these transformations (e.g. libxslt in Chromium) are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk.
For these reasons, I’d like to raise the question of whether we should deprecate and remove XSLT from the web standard.

Terence Eden:

August 1st - Googler asks the community if XSLT should be removed from the HTML living standard.
Respondents overwhelmingly reject the suggestion.
August 6th - Google starts work on removing XSLT from Chrome.
August 14th - Googler sends PR to remove XSLT from the standard.
Like, I don’t have a particular view of whether this is a good idea or not. But these sham community engagement exercises piss me off.

Most of the critical comments got marked as off-topic or duplicates, and then the bug was locked.

spankalee:

This isn’t Chrome doing this unilaterally. […] representatives from every browser are supportive and there have been discussions about this in standards meetings […] You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time.

Oblomov (via Hacker News):

What I want to talk about in this article is the war Google has been waging on XML for over a decade, why it matters that they’ve finally encroached themselves enough to get what they want, and what we can do to fight this.
[…]
Just as RSS feeds are making a comeback and users are starting to grow skeptic of the corporate silos, Google makes another run to kill XSLT, this time using the WHATWG as a sock puppet. Particularly of note, the corresponding Chromium issue was created before the WHATWG Github issue. It is thus to no one’s surprise that the overwhelmingly negative reactions to the issue, the detailed explanations about why XSLT is important, how instead of removing it browsers should move to more recent versions of the standard, and even the indications of existing better and more secure libraries to base such new implementations on, every counterpoint to the removal have gone completely ignored.

[…]

For example, he omitted that two new major versions of XSLT have been released since this technology was first implemented in the browsers: XSLT 2 in 2007, and XSLT 3 in 2017. This means that when Google first proposed to kill XSLT, a newer, considerably more powerful version of the standard had been released for six years already. And already at the time people were pleading for browsers support to be upgraded to the new version.

It is thus not by chance or by lack of resources that browsers are stuck with the 1999 XSLT 1: it has been an intentional choice against the users' will since at least 2013, the year we already mentioned as the turning point for the centralization of the web. XSLT has been intentionally boycotted by Google, Apple and Mozilla: using the excuse that it is not widely used today, after decades of undercutting any efforts in adoption, refusing to fix bugs or even to provide meaningful errors to assist in debugging related issues, is a complete mockery of the victims of these policy.