I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features.
Some of the things that stood out to me about the news:
- The thread by the Chromium dev proposed what was originally a 1MB minified polyfill for the Javascript only XSLT calls that in just the last few days has grown to 3MB minified. XSLT was beneficial in the browser because it was native, while a 3MB polyfill is a rather big ask to suggest as a per-site replacement for anything meant to be snappy on slower connections.
- It seems from various mentions the catalysts for this to surface now were the sole maintainer for the XSLT library used in Chromium expressed having trouble maintaining it some months back and left it to a different sole maintainer, along with a recently disclosed vulnerability in that particular library. Firefox OTOH is said to use a different XSLT library.
- Chromium team routinely awards vulnerability discovery bounties in the tens to hundreds of thousands of dollars. Just the other week they awarded $250k to an author who discovered a tricky Chromium exploit. I'd be curious if they've funded development of the XSLT library they use in the past as it seems like they'd rather just be rid of it.
- Within days of posting the open question to the working group and a week prior to the PR of the spec removal a Chromium ticket by the author set milestones for XSLT removal in Chromium. It seems it's less a tentative proposal and more leading by example.
I think a key problem here has nothing to do with the merits of XSLT, but is that some parties involved have no credibility when it comes to their intentions.
They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.
The people who use these features are busy using these features. And they are not part of browser development. So they revolt in a nasty manner. Like when ftp was torn down.
It is nice to see workarounds. But those workarounds are not conducive to HTML purists who do things without JS. They are the real web developers. They have always relied on the browser to improve and become faster but not start abandoning old technologies.
Chrome OS also became popular on this point that a browser can do things like being universal viewers and so the need for programs goes away. There are so many lite OS who are also using the browser to do everything.
Now I understand that the web has failed XML and XML failed the web in favor of JSON. I also whole heartedly believe that XML and XSLT can do so much more for the web and do this natively.
But open systems are not in the interest of the big FAANG and Microsoft ecosystem. They abandoned RSS. They abandon APIs on a regular basis. And this turn of events is causing browser vendors to start developing for big companies rather than open indie developers.
There is much gain from XML and XSLT. But I want to see a specific development. I want to see XSL import an XML. I want to see the reverse. XSL will be the view. XML will be the model. And the browser will be the controller. MVC paradigm.
That's good. It's good that everyone is on board with removing such a pointless feature that comes with a significant maintenance burden and security risks.
I hope some form of include makes it into the HTML standard and popular browser implementations before XSLT is gone. It’s perhaps the single largest gap in HTML’s capabilities and could reduce need for SSR, JS, and a build step in a lot of circumstances. Until now XSLT has been able to fill that gap for those who need that capability, but if it’s going away…
People have had some huge understandings of what's actually going on:
- That Mason opening issues means that it's a Google-effort. It's not.
- That the "Should we remove..." issue for community feedback. It's not. Spec issues are a collaboration vehicle for spec maintainers. There's not enough of the community on GitHub for that to be a good feedback mechanism.
- That Mason or Google hide comments and locked the thread. I heard from good authority that it was Apple employees actually, in their role as spec repo admins.
- That Google brought up the idea. The best I can see from meeting minutes is that a Mozilla rep did this time, though it's been brought up occasionally for 10 years at least.
- That the spec PR will be merged. At this point the PR is to show what it would mean to move XSLT from the spec.
- That decision has been made. These things are the beginning of the process.
- That XSLT even can be removed. Even though the vendors are tentatively in support, they are fully aware that this might not be viable in practice. I would guess that they think they can remove it, but they don't know for sure. They know usage numbers aren't always accurate, and they have ways of hedging bets like flags with different default in different channels, enterprise policies, reverse origin trials, etc.
A lot of that is irrelevant though. I don't think the problem is that Google might have unilaterally decided this, the problem is that there are unilateral decisions of this kind at all for a tech that affects billions of people.
(And I'm counting agreement between the handful of browser vendors as unilateral decisions as well. The group is not exactly very large)
The second part was basically the author saying "calm down guys, relax, there is a process." - and then speculating what that process might be.
If there is an orderly, public process that is being followed here, that includes a time and place for community feedback, shouldn't you be able to read up on it somewhere instead of speculating?
Wouldn't it be better if all interested parties band together and put forth a XML+XSLT-to-HTML translation with a common interface, and then integrate that?
XML/XSLT is a huge mess of a code base to implement correctly - especially XML parsing has been a fruitful source of exploits in the past. And it's not used in practice these days, it's been ages since I saw that used on the web out of RSS/Atom feeds (which are practically dead, for better or worse) and Java-based CMSes.
So from a technical standpoint, I do understand those calling for it to be eventually removed.
Fun fact - A very old version of the "WoW Armory", which was Blizzard Entertainment's World of Warcraft database at https://wowarmory.com/ used XSLT for all of its styling - though, IIRC, only on Firefox which was the only web browser to properly implement it.
The website's "item" and "character" pages were served entirely in XML.
I do not understand how this can possibly be considered. It comes down to one question: will this break websites that are in production right now?
If the answer is yes then it can't be done, simple as. I really don't care about anything else, you can't just break the web for people who are actively using it.
Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )
Just Firefox XSLT is faster, better than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox.
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues" ).
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free.
26 comments
[ 1960 ms ] story [ 1490 ms ] threadAlso also also: Really sorry, it's Pavlovian.
Obligatory: https://xkcd.com/1172/
1. all major vendors (google, mozilla, webkit) want to remove xslt
2. chrome does not have resources to support xslt
3. removing/disabling xslt will be a slow methodical process. don't panic.
4. when opening a proposal change, a pull request of code changes is mandatory to show exact changes; it is not a "countdown to merge"(sic)
5. info that leaks to the public should include context or links to full context
6. removing xslt support in browsers is not good or bad, but "it depends"
- The thread by the Chromium dev proposed what was originally a 1MB minified polyfill for the Javascript only XSLT calls that in just the last few days has grown to 3MB minified. XSLT was beneficial in the browser because it was native, while a 3MB polyfill is a rather big ask to suggest as a per-site replacement for anything meant to be snappy on slower connections.
- It seems from various mentions the catalysts for this to surface now were the sole maintainer for the XSLT library used in Chromium expressed having trouble maintaining it some months back and left it to a different sole maintainer, along with a recently disclosed vulnerability in that particular library. Firefox OTOH is said to use a different XSLT library.
- Chromium team routinely awards vulnerability discovery bounties in the tens to hundreds of thousands of dollars. Just the other week they awarded $250k to an author who discovered a tricky Chromium exploit. I'd be curious if they've funded development of the XSLT library they use in the past as it seems like they'd rather just be rid of it.
- Within days of posting the open question to the working group and a week prior to the PR of the spec removal a Chromium ticket by the author set milestones for XSLT removal in Chromium. It seems it's less a tentative proposal and more leading by example.
They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.
It is nice to see workarounds. But those workarounds are not conducive to HTML purists who do things without JS. They are the real web developers. They have always relied on the browser to improve and become faster but not start abandoning old technologies.
Chrome OS also became popular on this point that a browser can do things like being universal viewers and so the need for programs goes away. There are so many lite OS who are also using the browser to do everything.
Now I understand that the web has failed XML and XML failed the web in favor of JSON. I also whole heartedly believe that XML and XSLT can do so much more for the web and do this natively.
But open systems are not in the interest of the big FAANG and Microsoft ecosystem. They abandoned RSS. They abandon APIs on a regular basis. And this turn of events is causing browser vendors to start developing for big companies rather than open indie developers.
There is much gain from XML and XSLT. But I want to see a specific development. I want to see XSL import an XML. I want to see the reverse. XSL will be the view. XML will be the model. And the browser will be the controller. MVC paradigm.
- That Mason opening issues means that it's a Google-effort. It's not.
- That the "Should we remove..." issue for community feedback. It's not. Spec issues are a collaboration vehicle for spec maintainers. There's not enough of the community on GitHub for that to be a good feedback mechanism.
- That Mason or Google hide comments and locked the thread. I heard from good authority that it was Apple employees actually, in their role as spec repo admins.
- That Google brought up the idea. The best I can see from meeting minutes is that a Mozilla rep did this time, though it's been brought up occasionally for 10 years at least.
- That the spec PR will be merged. At this point the PR is to show what it would mean to move XSLT from the spec.
- That decision has been made. These things are the beginning of the process.
- That XSLT even can be removed. Even though the vendors are tentatively in support, they are fully aware that this might not be viable in practice. I would guess that they think they can remove it, but they don't know for sure. They know usage numbers aren't always accurate, and they have ways of hedging bets like flags with different default in different channels, enterprise policies, reverse origin trials, etc.
(And I'm counting agreement between the handful of browser vendors as unilateral decisions as well. The group is not exactly very large)
The second part was basically the author saying "calm down guys, relax, there is a process." - and then speculating what that process might be.
If there is an orderly, public process that is being followed here, that includes a time and place for community feedback, shouldn't you be able to read up on it somewhere instead of speculating?
XLST is a really weird feature and it seems sensible to drop it, be nice if there is a transparent solution for old software that uses it.
So from a technical standpoint, I do understand those calling for it to be eventually removed.
The website's "item" and "character" pages were served entirely in XML.
Here's a web archive: https://web.archive.org/web/20080220170805/https://wowarmory...
(dead_dove.gif)
If the answer is yes then it can't be done, simple as. I really don't care about anything else, you can't just break the web for people who are actively using it.
Should the web platform adopt XSLT 3.0? - https://news.ycombinator.com/item?id=44987552
Recent and also related:
XSLT removal will break multiple government and regulatory sites - https://news.ycombinator.com/item?id=44987346 - Aug 2025 (99 comments)
"Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 - Aug 2025 (523 comments)
Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
https://en.wikipedia.org/wiki/Efficient_XML_Interchange
Just Firefox XSLT is faster, better than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox.
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues" ).
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free.