- 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?
Last time I used XSLT in the browser was actually transforming PMML to JavaScript executable ML models about 10 yrs ago. Before that I think it was building a light weight web frontend for our SVN repo. With XML APIs replaced by json or binary formats, the relevance is becoming less and less. And in the end it is about legacy stuff only because there are XSLT compilers [0] that could fill the gap (maybe with a small web extension, that won't work on phones with native Apple and Google browsers...)
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.
5. Funny that we are talking about "info that leaks to the public" when we are discussing standards that may be important to billions of people, as if keeping things private was reasonable.
It's a poor choice of words by the GP. This was a public discussion, what would be private about it?
Rather it "leaked" from people with shared context to people without it. The point of the article is that since the discussion is public, there will be people that come across it without context, so it would be a good idea to include context in these kinds of discussions in the future:
> 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.
It does!
I run a small hobby site built with XML and XSLT because I'm not a great programmer, but XSLT is something I can actually wrap my head around and use without too much fuss. If support goes away I need to know how much time I have to rewrite/migrate my site to something else.
As a browser maker, why would you even put this work in for cordinated processes instead of investing in a way to patch away your native code and do that continuously at a slow pace for every aging feature?
Let's turn that around: are you willing to pay a browser vendor to keep supporting xslt so you can keep your codebase unchanged?
Do you think it matters to the guy that said he has an entire factory with IoT machinery that uses XSLT?
Should they shut the factory 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.
I don't think using one set of technologies as compared to another one can really be said to make one a "real" web developer. Real web developers are developers who put sites on the web, there is no benefit to anyone to be had claiming one choice is "real" and therefore the other choices are lesser-than.
Put it this way: whatever set of constraints you used to arrive at that decision does not apply to every situation, and when you frame things through the lens where you implicitly disregard that oh-so-obvious truth, it's hard for anyone to interpret your analysis as anything but myopic in the best case and actively self-serving and destructive in the worst case. It's nearly impossible to read through someone speaking this way about a topic and believe their analysis is objective, comprehensive, or without obvious bias, even if it may actually be all of those things.
FTP needed to be torn down. It’s sad, but true. There was no reason for anyone to be using it past 2010 - and in fact many reasons actively against using it
I kinda wish I could (S)FTP a lot more things than I can today.
I don't think they put SFTP in browsers yet.
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)
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)
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.
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.
With XSLT in a browser I can throw some static XML and XSLT files on any web server and they will Just Work™ and be usable without me having to do much other than telling the web server to serve index.xml instead of index.html. If I have to learn how to set up and maintain a proxy server so visitors to my site can still view the rendered pages, then I probably won't bother.
> XLST is a really weird feature and it seems sensible to drop it
What's weird about it? It lets me mark up some text using whatever XML makes sense to me and then write a template that the browser uses to transform it into (X)HTML that it can display. For someone who builds basic sites, it's an easy way to do templating that doesn't involve me setting up a 'real' programming environment
customElements.define(
"html-include",
class extends HTMLElement {
connectedCallback() {
fetch(this.getAttribute("href"))
.then((response) => response.text())
.then((text) => (this.innerHTML = text))}});
<include src="/shared/header.htmp”>
Uh the standard in question has existed for over two decades
Either way it’d allow several types of sites to have zero dependencies and no build step which is pretty cool.
onunload: https://developer.chrome.com/docs/web-platform/deprecating-u...
Mutation events (replaced by MutationObserver): https://developer.chrome.com/blog/mutation-events-deprecatio...
FTP URLs: https://developer.chrome.com/blog/deps-rems-95#ftp_support_r...
Here's useful documentation on their process, which they sometimes call Chrome Variations and sometimes Origin Trials: https://developer.chrome.com/docs/web-platform/chrome-variat...
Outside of web browsers, i think X11 is somewhat famous for this sort of thing.
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.
Flash was a third party plugin that got way out of hand. It wasn’t (necessarily) the job the browser vendors created for themselves and offered for years.
Flash was also moreso removed on a fledgling platform first that grew to be a dominant platform; it wasn’t killed off on an existing dominant platform first.
This is what happens when you have a monopoly.
We could remove framesets and remove var from javascript. Remove the Date object now that there is a Temporal api. Remove tables and flexbox now that there is grid. xhr can go too now that we have fetch. The <center> tag isn't needed anymore. I'm sure we can find support from people disliking onclick and onsomething attributes. Or how about hoisting? Surely we can simply rm that? Removing things doesn't have to be limited to older things. asm.js and web workers weren't really necessary at all.
I'm fountain of good ideas.
So from a technical standpoint, I do understand those calling for it to be eventually removed.
Also also also: Really sorry, it's Pavlovian.
Obligatory: https://xkcd.com/1172/
But the argument is mostly irrelevant here. This is a web platform feature. One of the defining characteristics of the web platform is to be very conservative with backwards compatibility. This has nothing to do with it being OSS.
Sometimes yes, but just as often in corporate world, what happens is that they decide that the feature isnt going to increase growth, so it doesn't make sense to keep it. I think in corporate world xslt would have been killed long long ago.
> This has nothing to do with it being OSS.
It has everything to do with the standard being maintained in the style of open source. The reason why google is getting flak despite firefox being the one to propose killing it is because the google employee is the one opening a github issue.
As opposed to non-OSS, where removing features that paying customers care about is of course trivial?
> Obligatory: https://xkcd.com/1172/
I don't mindless comic and its original context, but it's gotten extremely old seeing it wheeled out to justify completely discarding user input on any change. Sometimes an update does break legitimate workflows, and that is bad.
When the amount they are paying you is much less then the amount it costs to maintain it is, then yes it is usually fairly easy.
They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.
There is really no winning for them. They weren't even the party who proposed removing xslt.
Like HN isn't on these type of topics. Just an hour ago you said that they're trying to kill XSLT because it "not a tool for surveillance capitalism"[1]. A claim made completely unencumbered by any evidence, of course. It's little more than a nonsensical conspiracy theory.
There's a reason all the major browsers are kind of on-board with this, just like there's a reason it never got updated much beyond XSLT 1. If XSLT would be proposed today, adding it to browsers would be a complete non-starter. Newer browsers like Servo or Ladybird have not even mentioned XSLT as near as I can find. It's very low low on their priority list, and I wouldn't be surprised if at least some people working on those browsers would prefer to not implement it at all.
The funny thing about people stuck in echo chambers is that they cannot comprehend how anyone could disagree with them, so then they reach to conspiracy theories to "explain" this, completely ignoring all the technical arguments.
If HTML didn't exist and was proposed today (please forgive the forced hypothetical) it would be a non-starter. Every tech-startup would instead want you to use their dedicated app. We rarely create shared standards or protocols anymore. We should at least keep the ones we have.
1. "Play Nice": Browser vendors are trying to do what’s right for the web with budgets that are substantially outside their control. But browser vendors have the right to control their budgets, and to make decisions about what features to support or not to support. Web developers have to persuade browser vendors in order to get what they want; they have no special moral rights here. It is both practical and ethical to treat browser vendors politely, and not to rudely shame them.
(Eric Meyer's blog post here is firmly in the "Play Nice" point of view. "Google has trillions of dollars," he writes. "The Chrome team very much does not.")
2. "Fight the Power": Browser vendors are in a position of power, and that creates a moral responsibility to web developers. Their budgets are substantially within their control, and if their moral duty requires them to spend more on browser development, then that’s what duty requires. Frequently, browser vendors will try to shirk their duty to web developers in order to manage their budgets; this is always wrong, every time they do it.
There are two sub-bullets under "Fight the Power."
2a. When browser vendors shirk their responsibility, we all have a duty to shame the ones doing it in a noisy protest, not because that’s a practical way to persuade browser vendors, but because protesting/shaming wrongdoers in positions of power is ethical for its own sake.
2b. Browser vendors will try to shield themselves from protests by putting “code of conduct” rules in place against protesting/shaming them, especially against personal attacks. But it’s unethical for browser vendors (actors in a position of power) to enforce a code of conduct that prevents powerless web devs from shaming them, so the code of conduct should be protested, too; browser vendors should furthermore be shamed for having a code of conduct that interferes with the right/duty of web devs to protest shameful behavior. At a minimum, web devs should non-violently resist the code of conduct by actively violating it, and by shaming browser vendors for trying to enforce it.
I think the majority point of view here on HN is "Fight the Power." Google's up to no good, again, huh? Then we've all gotta shame them into doing the right thing again with a righteous flame war, no holds barred, including direct personal attacks. ("Should Mason Freed be removed from web standards?")
And if they try to delete/suppress our flamey personal-attack posts calling out their shameful behavior, why, that's even more shameful, and we've gotta call that out, too.
I think both points of view are reasonable. The problem is when people don't even realize that the other point of view exists.
One of the things I learned about Google during the AMP4Email fiasco is that the standards-development folks there... do not know the word no. There is no process to tell them that something should not be done. If you do, you broke the code of conduct, because they're Googlers and they Know Better. People like Mason Freed in the XSLT thread are sad that people trying to tell him no are getting in the way of him talking to people who will tell him yes.
At the point where the courts have determined that Google abuses it's monopoly control of the web, honestly, there's a question why Google is involved in standards-setting as opposed to being relegated to an advisory position required to implement standards as-designed by everyone else.
The venue is the right to fork.
The standard is made by people who write code implementing web browsers. Rando freeloaders who don't put in the work don't get a vote.
This is how the internet has always worked, to pataphrase a different standards body - running code and loose consensus.
The web is what the engines implement and what sites use. Always has been. A standard that's not implemented isn't worth anything.
Web standards exist to help browsers be interoperable. Before them one browser would implement something, and if another liked it they would too. That can still happen, but standards mediate the process to be less chaotic and more reliable.
Web standards cannot force browsers to do anything. If a browser doesn't implement a standard - and there are lot of unimplemented "standards" out there - then it just doesn't.
As a user then you have the choice to use browsers that offer better or different standards support. If you require XSLT support, and Firefox removes it, you can use Safari, or Chrome. If Chrome removes it, you can hopefully use an Blink engine that keeps the feature on (usually they're removed with a flag far before they're actually deleted with code).
And this is the real problem with a lack of browser diversity: Users need to be able to vote with their feet.
But... if all the vendors agree on something, as a user good luck with finding an alternative. I seriously doubt Opera, Brave, or Vivaldi is going to do the work and take the security risk to add back XSLT. Servo and Ladybird aren't going to come to the rescue here either. They most likely would love to have less to implement.
Don't you think you're being a little bit dramatic? The chances of anybody who isn't an ubernerd caring about XSLT's removal is exactly 0.