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.
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.
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.
Fun fact: David Karp saved the world from XSLT being Tumblr’s blog-theme language.
Previously:
Update (2025-09-04): Eric Meyer (Hacker News):
As a very quick background, various people have proposed removing XSLT support from browsers a few times over the quarter-century-plus since support first landed. It was discussed in both the early and mid-2010s, for example. At this point, browsers all more or less support XSLT 1.0, whereas the latest version of XSLT is 3.0. I believe they all do so with C++ code, which is therefore not memory-safe, that is baked into the code base rather than supported via some kind of plugged-in library, like Firefox using PDF.js to support PDFs in the browser.
[…]
First of all, while Mason was the one to open the issue, this was done because the idea was raised in a periodic WHATNOT meeting (call), where someone at Mozilla was actually the one to bring it up, after it had come up in various conversations over the previous few months. After Mason opened the issue, members of the Mozilla and WebKit teams expressed (tentative, mostly) support for the idea of exploring this removal. Basically, none of the vendors are particularly keen on keeping native XSLT support in their codebases, particularly after security flaws were found in XSLT implementations.
[…]
Mason mentioned that they didn’t have resources to put toward updating their XSLT code, and got widely derided for it. “Google has trillions of dollars!” people hooted. Google has trillions of dollars. The Chrome team very much does not. They probably get, at best, a tiny fraction of one percent of those dollars. Whether Google should give the Chrome team more money is essentially irrelevant, because that’s not in the Chrome team’s control.
[…]
That said, as a result of all this, I now strongly believe that every proposed-removal issue should point to the process and where the issue stands in it. (And write down the process if it hasn’t been already.) This isn’t for the issue’s intended audience, which was other people within WHATWG who are familiar with the usual process and each other, but for cases of context escape, like happened here. If a removal discussion is going to be held in public, then it should assume the general public will see it and provide enough context for the general public to understand the actual nature of the discussion. In the absence of that context, the nature of the discussion will be assumed, and every assumption will be different.
Dmitrii Dimandt (Hacker News):
XSLT removal will break multiple government and regulatory sites across the world
Should the web platform adopt XSLT 3.0?
4 Comments RSS · Twitter · Mastodon
I figure that anything that’s removed from browsers makes it easier, however minutely, to unseat Chrome’s monopoly status in the browser space.
I’m thinking of Ladybird mostly, but I figure this applies to Safari and Firefox as well.
Can anyone think of a counterexample?
This is morbidly fascinating. I’m a huge fan of both XML and XSLT. I’ve used them for at least 20 years and my current software absolutely depends on them. I can do things with them that are flat out impossible any other way. And yet, I feel that XSLT should obviously be removed from web standards.
No one would ever admit how much social pressures drive technology. Technologies like XML, XSLT, and Perl mostly serve as fodder for making fun of the “crusty” greybeards. The state of the art rich text these days is “markdown”, a technology that seems ripped right from the 1970s.
This situation is so funny because RSS is still considered cool and displaying XML RSS feeds is probably the only thing that web XSLT was ever used for. There are two different camps of cool kids fighting. I’m delighted.
>Googler asks the community if XSLT should be removed from the HTML living standard.
>
>Respondents overwhelmingly reject the suggestion.
This is quite misleading. The sixth comment, which is the first reply on whether this is good or bad, is Anne from the WebKit team cautiously _supporting_ Google's move.
Now, the real question is: what does removing it from the "web platform" imply? I think
* _directly_, all it means is that browsers are no longer expected to have built-in XSLT support. To Nathan's point, that may arguably be a good thing. Critically, this does not kill or deprecate the spec. It merely deprecates _browsers shipping with it_.
* now, _indirectly_, this may indeed have effects on how much funding and other support XSLT gets in the future. But let's be real: how much support has XSLT enjoyed in the past two decades? When was the last time you wrote XSLT? Or even looked at an XSLT file? Or even just explicitly _used_ one?
>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.
If you're really using RSS to read feeds or listen to podcasts _in the web browser_ (which, first of all, just use a native app), then odds are A) that web app doesn't use XSLT in the first place (just use XPath, or something even simpler), B) if it does, it probably happens server-side and thus isn't affected at all, and C) if your feed reader _really_ wants to use XSLT _in the web browser_ for this, it can use one of the many JS packages on npm that do not rely on the browser's built-in XSLT, and have support for newer specs to boot.
> these sham community engagement
I don't think votes on a GH issue are a great reflection on how "the community" (whoever that is) feels any more than review-bombed movies and series are an indication of whether those people watched the film or enjoyed it. There's too high a risk of mob justice rather than genuine engagement. How do the makers of big browsers feel? How about those who maintain XSLT libraries? Those are the questions that should be asked. Not, "how many randos with a GitHub account can drive by and hit the thumbs-down button because big corporation bad".
I see no "Google bad" story here (leaving aside that other browser vendors seem to be in agreement); I see a case of people clinging to an overcomplicated spec from a quarter century ago that frankly was never that great to begin with, but _it could have been_. Sure. Just like "the semantic web" or XHTML 2 could've been. But they weren't. And neither, perhaps, is the idea of putting XSLT in the browser.
@Sören I think XSLT is pretty useful and have used it both in my apps and in web code. I haven’t needed it in the browser, though, unless I was unaware that it was being used to render an XML document for display.
