11 ms·

Google did not unilaterally decide to kill XSLT

103 points by bkardell 1y ago

lysace 1y ago
Also: It deserved to die
- nativeit 1y ago
  Also also: You hope it burns in hell? Also also also: Really sorry, it's Pavlovian.
fancyfredbot 1y ago
[flagged]
hobs 1y ago
I like how the resource issue is hand waived away because some random manager decided not to do it, and that's somehow a force of nature now.
- WJW 1y ago
  Well yes? People get to decide what to do with their own money, and managers get to decide what to do with the companies' money. That's basically what being a manager means in the first place. They decided spending that money on maintaining a barely used feature was not a very good use of the budget, and that it might be better spent on something that people actually use.
  - hobs 1y ago
    And so would that be a thing we can maybe have an issue with? The entire "handwaving away" bit is the fact that moving a decision another layer up a hierarchy doesn't change who is responsible or how that responsibility manifests, a different problem then "they get to decide on how they spend their money" - we don't have the resources vs we are not going to use them on what you want (which itself is something that is up for say, an influence campaign.)
    - WJW 1y ago
      You can have an issue with that if you want, but I won't be joining you. Put up your own money (or time!) if you want to keep XSLT. Personally I think there are many better ways to spend money than on features nobody uses. Even just giving the money back to shareholders via buybacks or dividends would be better than doing useless work on purpose.
- warkdarrior 1y ago
  People who want that feature to stay in the browsers should put up some money to fund continued development and maintenance.
  - hobs 1y ago
    Sure, but that's a different argument entirely - we don't have money vs you should be spending the money.
  - basscomm 1y ago
    The problem with this is that it incentivizes browsers to only implement features if it makes them money and to remove everything else.
bawolff 1y ago
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. Obligatory: https://xkcd.com/1172/ https://xkcd.com/1172/
- sfink 1y ago
  That's how it happens in OSS development. For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version. See also the fabled backwards compatibility hacks in Windows and graphics drivers. Whether OSS or proprietary software has it worse, I can't even guess. 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.
  - bawolff 1y ago
    > For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version 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.
- yjftsjthsd-h 1y ago
  > 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. As opposed to non-OSS, where removing features that paying customers care about is of course trivial? > Obligatory: https://xkcd.com/1172/ 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.
bevr1337 1y ago
A/B testing the removal of a browser standard gives me pause. Is there precedent for that?
- bawolff 1y ago
  SameSite by default cookies come to mind: https://www.chromium.org/updates/same-site/ https://www.chromium.org/updates/same-site/ (and to be clear, this is a removal of functionality. The "feature" is to make cookies not work in certain contexts) Outside of web browsers, i think X11 is somewhat famous for this sort of thing.
- simonw 1y ago
  Yes, they've done it before. Some example: onunload: https://developer.chrome.com/docs/web-platform/deprecating-unload https://developer.chrome.com/docs/web-platform/deprecating-u... Mutation events (replaced by MutationObserver): https://developer.chrome.com/blog/mutation-events-deprecation https://developer.chrome.com/blog/mutation-events-deprecatio... FTP URLs: https://developer.chrome.com/blog/deps-rems-95#ftp_support_removed 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-variations https://developer.chrome.com/docs/web-platform/chrome-variat...
  - th0ma5 1y ago
    They may be talking about actually removing whole standards not just specifics of standards like this. FTP is close but it was always adjacent to web browsing. Perhaps HTTP 1.0 removal is closest, but is a different level of abstraction than XSLT which is potentially and subtly everywhere.
- EmuAGR 1y ago
  They removed JXL support just when it was increasing popularity so it didn't interfere with their AVIF plans.
sugarpimpdorsey 1y ago
[flagged]
- bawolff 1y ago
  MS doesn't even make a browser engine.
- simonw 1y ago
  Which comments did you see as being arrogant?
  - sugarpimpdorsey 1y ago
    The one where the guy speaks for the whole Chrome team and says they want work on new stuff rather than fix things they themselves allege are broken. It's extremely ivory tower and a disservice to the web as a whole.
    - chatmasta 1y ago
      Idk, this seems like pretty standard communications for a committee-driven process…
    - madeofpalk 1y ago
      Wait - have you never said something similar? That would would rather address tech debt, or drop a feature that gets little use and has high maintance cost, so you can spend your effort on "better" things?
      - danaris 1y ago
        There's a big difference between removing something to address tech debt in an internal system, or even a normal application, and removing support for a web standard from Google Chrome. It's the single most popular browser on the internet today, so removing support for any given standard from it means, effectively, breaking anything that uses that standard on the web. And because XSLT isn't a particularly user-visible standard, there's no easy way to tell which websites will use it, and any website that breaks because of it will just appear not to be supporting Chrome, rather than the other way around. (Flash, for instance, was a much more visible feature, and it was generally very clear when a website broke because it was using Flash when support went away. Plus, of course, it was not a web standard.)
throw7 1y ago
My jotted down notes: 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"
- dkiebd 1y ago
  3. It will eventually be removed. Does it matter whether it will take three months or three years? Since I suppose none of the browser vendors will give developers money to change their xslt usage in codebases for something else. 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.
  - basscomm 1y ago
    > Does it matter whether it will take three months or three years? 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.
  - magicalist 1y ago
    > Funny that we are talking about "info that leaks to the public" 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.
  - 1y ago
_bzuf 1y ago
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.
- simonw 1y ago
  Are you talking about Google as a whole?
- ocdtrekkie 1y ago
  This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The web is ours, not theirs. And I think we should rightfully set fire to the WHATWG's implementation discussions until they recognize that fact. 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.
  - deleted 1y ago
    [deleted]
  - samdoesnothing 1y ago
    > while they destroy the web 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.
    - th0ma5 1y ago
deleted 1y ago
[deleted]
nashashmi 1y ago
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.
- karlgkk 1y ago
  > Like when ftp was torn down 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
  - nashashmi 1y ago
    It was a quick way to share files. FTP as an internet application made a lot of sense. The only counter reason was it did not have password protections like SFTP did, and did not support encryption. But that is like arguing against HTTP in favor of HTTPS. I don't think they put SFTP in browsers yet.
    - notpushkin 1y ago
      There was FTPS (FTP+TLS). Not sure if browsers ever supported that but I imagine it’s not too hard to implement iv you have HTTPS already.
samdoesnothing 1y ago
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.
- sugarpimpdorsey 1y ago
  That's a great view to have if you're someone that switches jobs every six months and never supports anything for any meaningful length of time.
  - jeltz 1y ago
    XSLT in the browser was always a bad idea.
    - giantrobot 1y ago
      What? XSLT in the browser is an awesome idea. It let web sites publish data unencumbered by presentation and let the client's user agent decide how to use the data. Your browser can download the XML and use a linked XSL stylesheet to display it for a graphical browser. That exact same data resource could be used instead by a program that understands the schema of the data and do some custom thing with it. There's no need to trust some giant blob of JavaScript to convert a data document into a usable web page. Just the native XSLT engine (using the same XML processing pipeline it uses for all the other XML it encounters). A web of XML documents could all be easily viewable by a web browser but the exact same data can be processed with other tools. There's a lot of old web API ideas being recycled (poorly) with JSON to service AI tools today. The web could have already been nicely structured data easily ingested by autonomous tools (AI or not) while at the same time being still perfectly accessible by graphical web browsers. But no, everyone decided that because Enterprise XML Usage was icky so they needed to completely throw out XML in favor of a much shittier serialization format.
      - jeltz 1y ago
        The reason it is a bad idea is because XML, XSLT and related standards are almost impossible to implement. I don't think there is any non-broken implementation of it. The idea behind it is interesting but the actual standards and libraries involved are awful.
cosmic_cheese 1y ago
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…
- samdoesnothing 1y ago
  There is no point of introducing yet another standard to do something that can be done in few lines of JS. customElements.define( "html-include", class extends HTMLElement { connectedCallback() { fetch(this.getAttribute("href")) .then((response) => response.text()) .then((text) => (this.innerHTML = text))}}); The browser has had a powerful scripting language built in as a core primitive for decades, and yet people would rather create more standards to avoid using it for ideological reasons, and then complain that there aren't enough competing browsers.
  - sugarpimpdorsey 1y ago
    > yet people would rather create more standards to avoid using it for ideological reasons Uh the standard in question has existed for over two decades
  - cosmic_cheese 1y ago
    That’s not nearly as nice as being able to drop a… <include src="/shared/header.htmp”> …in anywhere you want a header. It being part of HTML also allows engines to optimize in ways that otherwise wouldn’t be possible and implement user-toggleable features like lazy loading. It can get better as browsers get better and is less likely to break than any custom JS I write.
  - naniwaduni 1y ago
    It's something that people keep reinventing on both sides of the connection. That XSLT is the better of two terrible ways to do it, and that you're making the argument that the other one still exists, is an embarrassment.
spankalee 1y ago
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.
- xg15 1y ago
  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?
  - riedel 1y ago
    I would agree to see the outcry more as a symptom about this meritocratic system. I think we are at a point where new browser/rendering engines are developing like ladybird or Servo. An independent group should make sure that they will strive. Making specs simpler can help here. But I think many things are done for the wrong reasons (E.g. Google wanting to cut down cost on parts irrelevant to their income, other vendors that are reliant on them). 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...) [0] https://github.com/egh/xjslt https://github.com/egh/xjslt
pjmlp 1y ago
Remember similar arguments were made not to support WebGL 2.0 Compute, also from Chrome team, because WebGPU was going to be much better.
pdntspa 1y ago
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?
- 6510 1y ago
  I have lots of ideas for things that can just be removed. 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.
  - ameliaquining 1y ago
    The idea is not to just remove things for the sake of removing things, but to engage in a cost-benefit analysis. Most of the things listed above either are very widely used or don't cost much or have other downsides to maintain. By contrast, when things have been removed from the Web platform in the past, it was because they were causing problems out of proportion to the amount of breakage induced by removing them. In the case of XSLT, the problem is the attack surface that it adds.
    - 6510 1y ago
      Reading online for a bit it seems cors already ruined much of the fun. If you think about it, even with the "*" header you end up with a html document served from a different place than the url would suggest. Kinda sad since slapping a generic template onto some familiar xml implementation seems a wonderful thing. I've always wanted browsers to provide a set of standard templates. 90% of the time I don't care about the design, I just want something functional right now.
paulsutter 1y ago
Is there any reason this cant be solved with a proxy server? So that legacy software that uses XLST can still run on the new browsers that lack it? 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.
- basscomm 1y ago
  > Is there any reason this cant be solved with a proxy server? So that legacy software that uses XLST can still run on the new browsers that lack 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
mschuster91 1y ago
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.
- wpollock 1y ago
  >it's been ages since I saw that [XML/XSLT] used on the web out of RSS/Atom feeds (which are practically dead, for better or worse)... Not dead. I read HN using their feed!
- nativeit 1y ago
  I clicked through to this comment section via HN RSS feeds.
scrollaway 1y ago
Fun fact - A very old version of the "WoW Armory", which was Blizzard Entertainment's World of Warcraft database at https://wowarmory.com/ 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. Here's a web archive: https://web.archive.org/web/20080220170805/https://wowarmory.com/ https://web.archive.org/web/20080220170805/https://wowarmory... (dead_dove.gif)
worble 1y ago
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.
- spankalee 1y ago
  Removing Flash, Mutation Events, and third-party cookies broke websites.
  - Klonoar 1y ago
    Look man, Flash was not the same thing and people need to stop bringing this up. 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.
    - 8NNTt8z3QvLT8tp 1y ago
      You've completely disregarded the other examples of breaking changes that have already been made. The open web still survives afterwards. The web isn't immutable no matter how much people might want it to be.
      - Klonoar 1y ago
        No, I didn't. Did you even read my comment? I called out Flash. I could not have written a more straightforward note about how their comment was set up. Nothing I said indicated I disagree with their overall stance, just that Flash is a ridiculous thing to trot out.
- danaris 1y ago
  I mean, of course they can. They're Google. What are you going to do, stop using Chrome and searching with Google and using Gmail and buying AdWords and....etc? This is what happens when you have a monopoly.
dang 1y ago
Related ongoing thread: Should the web platform adopt XSLT 3.0? - https://news.ycombinator.com/item?id=44987552 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 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 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 https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
scotty79 1y ago
I hope that if they decide to update XSLT they'll also implement this: https://en.wikipedia.org/wiki/Efficient_XML_Interchange https://en.wikipedia.org/wiki/Efficient_XML_Interchange
thro1 1y ago
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-3213412959 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.

103 points by bkardell 1y ago

lysace 1y ago

Also: It deserved to die

nativeit 1y ago
Also also: You hope it burns in hell? Also also also: Really sorry, it's Pavlovian.

fancyfredbot 1y ago

[flagged]

hobs 1y ago

I like how the resource issue is hand waived away because some random manager decided not to do it, and that's somehow a force of nature now.

WJW 1y ago
Well yes? People get to decide what to do with their own money, and managers get to decide what to do with the companies' money. That's basically what being a manager means in the first place. They decided spending that money on maintaining a barely used feature was not a very good use of the budget, and that it might be better spent on something that people actually use.
- hobs 1y ago
  And so would that be a thing we can maybe have an issue with? The entire "handwaving away" bit is the fact that moving a decision another layer up a hierarchy doesn't change who is responsible or how that responsibility manifests, a different problem then "they get to decide on how they spend their money" - we don't have the resources vs we are not going to use them on what you want (which itself is something that is up for say, an influence campaign.)
  - WJW 1y ago
    You can have an issue with that if you want, but I won't be joining you. Put up your own money (or time!) if you want to keep XSLT. Personally I think there are many better ways to spend money than on features nobody uses. Even just giving the money back to shareholders via buybacks or dividends would be better than doing useless work on purpose.
warkdarrior 1y ago
People who want that feature to stay in the browsers should put up some money to fund continued development and maintenance.
- hobs 1y ago
  Sure, but that's a different argument entirely - we don't have money vs you should be spending the money.
- basscomm 1y ago
  The problem with this is that it incentivizes browsers to only implement features if it makes them money and to remove everything else.

bawolff 1y ago

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. Obligatory: https://xkcd.com/1172/ https://xkcd.com/1172/

sfink 1y ago
That's how it happens in OSS development. For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version. See also the fabled backwards compatibility hacks in Windows and graphics drivers. Whether OSS or proprietary software has it worse, I can't even guess. 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.
- bawolff 1y ago
  > For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version 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.
yjftsjthsd-h 1y ago
> 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. As opposed to non-OSS, where removing features that paying customers care about is of course trivial? > Obligatory: https://xkcd.com/1172/ 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.

bevr1337 1y ago

A/B testing the removal of a browser standard gives me pause. Is there precedent for that?

bawolff 1y ago
SameSite by default cookies come to mind: https://www.chromium.org/updates/same-site/ https://www.chromium.org/updates/same-site/ (and to be clear, this is a removal of functionality. The "feature" is to make cookies not work in certain contexts) Outside of web browsers, i think X11 is somewhat famous for this sort of thing.
simonw 1y ago
Yes, they've done it before. Some example: onunload: https://developer.chrome.com/docs/web-platform/deprecating-unload https://developer.chrome.com/docs/web-platform/deprecating-u... Mutation events (replaced by MutationObserver): https://developer.chrome.com/blog/mutation-events-deprecation https://developer.chrome.com/blog/mutation-events-deprecatio... FTP URLs: https://developer.chrome.com/blog/deps-rems-95#ftp_support_removed 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-variations https://developer.chrome.com/docs/web-platform/chrome-variat...
- th0ma5 1y ago
  They may be talking about actually removing whole standards not just specifics of standards like this. FTP is close but it was always adjacent to web browsing. Perhaps HTTP 1.0 removal is closest, but is a different level of abstraction than XSLT which is potentially and subtly everywhere.
EmuAGR 1y ago
They removed JXL support just when it was increasing popularity so it didn't interfere with their AVIF plans.

sugarpimpdorsey 1y ago

[flagged]

bawolff 1y ago
MS doesn't even make a browser engine.
simonw 1y ago
Which comments did you see as being arrogant?
- sugarpimpdorsey 1y ago
  The one where the guy speaks for the whole Chrome team and says they want work on new stuff rather than fix things they themselves allege are broken. It's extremely ivory tower and a disservice to the web as a whole.
  - chatmasta 1y ago
    Idk, this seems like pretty standard communications for a committee-driven process…
  - madeofpalk 1y ago
    Wait - have you never said something similar? That would would rather address tech debt, or drop a feature that gets little use and has high maintance cost, so you can spend your effort on "better" things?
    - danaris 1y ago
      There's a big difference between removing something to address tech debt in an internal system, or even a normal application, and removing support for a web standard from Google Chrome. It's the single most popular browser on the internet today, so removing support for any given standard from it means, effectively, breaking anything that uses that standard on the web. And because XSLT isn't a particularly user-visible standard, there's no easy way to tell which websites will use it, and any website that breaks because of it will just appear not to be supporting Chrome, rather than the other way around. (Flash, for instance, was a much more visible feature, and it was generally very clear when a website broke because it was using Flash when support went away. Plus, of course, it was not a web standard.)

throw7 1y ago

My jotted down notes: 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"

dkiebd 1y ago
3. It will eventually be removed. Does it matter whether it will take three months or three years? Since I suppose none of the browser vendors will give developers money to change their xslt usage in codebases for something else. 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.
- basscomm 1y ago
  > Does it matter whether it will take three months or three years? 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.
- magicalist 1y ago
  > Funny that we are talking about "info that leaks to the public" 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.
- 1y ago

_bzuf 1y ago

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.

simonw 1y ago
Are you talking about Google as a whole?
ocdtrekkie 1y ago
This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The web is ours, not theirs. And I think we should rightfully set fire to the WHATWG's implementation discussions until they recognize that fact. 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.
- deleted 1y ago
  [deleted]
- samdoesnothing 1y ago
  > while they destroy the web 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.
  - th0ma5 1y ago

deleted 1y ago

[deleted]

nashashmi 1y ago

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.

karlgkk 1y ago
> Like when ftp was torn down 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
- nashashmi 1y ago
  It was a quick way to share files. FTP as an internet application made a lot of sense. The only counter reason was it did not have password protections like SFTP did, and did not support encryption. But that is like arguing against HTTP in favor of HTTPS. I don't think they put SFTP in browsers yet.
  - notpushkin 1y ago
    There was FTPS (FTP+TLS). Not sure if browsers ever supported that but I imagine it’s not too hard to implement iv you have HTTPS already.

samdoesnothing 1y ago

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.

sugarpimpdorsey 1y ago
That's a great view to have if you're someone that switches jobs every six months and never supports anything for any meaningful length of time.
- jeltz 1y ago
  XSLT in the browser was always a bad idea.
  - giantrobot 1y ago
    What? XSLT in the browser is an awesome idea. It let web sites publish data unencumbered by presentation and let the client's user agent decide how to use the data. Your browser can download the XML and use a linked XSL stylesheet to display it for a graphical browser. That exact same data resource could be used instead by a program that understands the schema of the data and do some custom thing with it. There's no need to trust some giant blob of JavaScript to convert a data document into a usable web page. Just the native XSLT engine (using the same XML processing pipeline it uses for all the other XML it encounters). A web of XML documents could all be easily viewable by a web browser but the exact same data can be processed with other tools. There's a lot of old web API ideas being recycled (poorly) with JSON to service AI tools today. The web could have already been nicely structured data easily ingested by autonomous tools (AI or not) while at the same time being still perfectly accessible by graphical web browsers. But no, everyone decided that because Enterprise XML Usage was icky so they needed to completely throw out XML in favor of a much shittier serialization format.
    - jeltz 1y ago
      The reason it is a bad idea is because XML, XSLT and related standards are almost impossible to implement. I don't think there is any non-broken implementation of it. The idea behind it is interesting but the actual standards and libraries involved are awful.

cosmic_cheese 1y ago

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…

samdoesnothing 1y ago
There is no point of introducing yet another standard to do something that can be done in few lines of JS. customElements.define( "html-include", class extends HTMLElement { connectedCallback() { fetch(this.getAttribute("href")) .then((response) => response.text()) .then((text) => (this.innerHTML = text))}}); The browser has had a powerful scripting language built in as a core primitive for decades, and yet people would rather create more standards to avoid using it for ideological reasons, and then complain that there aren't enough competing browsers.
- sugarpimpdorsey 1y ago
  > yet people would rather create more standards to avoid using it for ideological reasons Uh the standard in question has existed for over two decades
- cosmic_cheese 1y ago
  That’s not nearly as nice as being able to drop a… <include src="/shared/header.htmp”> …in anywhere you want a header. It being part of HTML also allows engines to optimize in ways that otherwise wouldn’t be possible and implement user-toggleable features like lazy loading. It can get better as browsers get better and is less likely to break than any custom JS I write.
- naniwaduni 1y ago
  It's something that people keep reinventing on both sides of the connection. That XSLT is the better of two terrible ways to do it, and that you're making the argument that the other one still exists, is an embarrassment.

spankalee 1y ago

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.

xg15 1y ago
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?
- riedel 1y ago
  I would agree to see the outcry more as a symptom about this meritocratic system. I think we are at a point where new browser/rendering engines are developing like ladybird or Servo. An independent group should make sure that they will strive. Making specs simpler can help here. But I think many things are done for the wrong reasons (E.g. Google wanting to cut down cost on parts irrelevant to their income, other vendors that are reliant on them). 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...) [0] https://github.com/egh/xjslt https://github.com/egh/xjslt

pjmlp 1y ago

Remember similar arguments were made not to support WebGL 2.0 Compute, also from Chrome team, because WebGPU was going to be much better.

pdntspa 1y ago

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?

6510 1y ago
I have lots of ideas for things that can just be removed. 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.
- ameliaquining 1y ago
  The idea is not to just remove things for the sake of removing things, but to engage in a cost-benefit analysis. Most of the things listed above either are very widely used or don't cost much or have other downsides to maintain. By contrast, when things have been removed from the Web platform in the past, it was because they were causing problems out of proportion to the amount of breakage induced by removing them. In the case of XSLT, the problem is the attack surface that it adds.
  - 6510 1y ago
    Reading online for a bit it seems cors already ruined much of the fun. If you think about it, even with the "*" header you end up with a html document served from a different place than the url would suggest. Kinda sad since slapping a generic template onto some familiar xml implementation seems a wonderful thing. I've always wanted browsers to provide a set of standard templates. 90% of the time I don't care about the design, I just want something functional right now.

paulsutter 1y ago

Is there any reason this cant be solved with a proxy server? So that legacy software that uses XLST can still run on the new browsers that lack it? 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.

basscomm 1y ago
> Is there any reason this cant be solved with a proxy server? So that legacy software that uses XLST can still run on the new browsers that lack 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

mschuster91 1y ago

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.

wpollock 1y ago
>it's been ages since I saw that [XML/XSLT] used on the web out of RSS/Atom feeds (which are practically dead, for better or worse)... Not dead. I read HN using their feed!
nativeit 1y ago
I clicked through to this comment section via HN RSS feeds.

scrollaway 1y ago

Fun fact - A very old version of the "WoW Armory", which was Blizzard Entertainment's World of Warcraft database at https://wowarmory.com/ 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. Here's a web archive: https://web.archive.org/web/20080220170805/https://wowarmory.com/ https://web.archive.org/web/20080220170805/https://wowarmory... (dead_dove.gif)

worble 1y ago

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.

spankalee 1y ago
Removing Flash, Mutation Events, and third-party cookies broke websites.
- Klonoar 1y ago
  Look man, Flash was not the same thing and people need to stop bringing this up. 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.
  - 8NNTt8z3QvLT8tp 1y ago
    You've completely disregarded the other examples of breaking changes that have already been made. The open web still survives afterwards. The web isn't immutable no matter how much people might want it to be.
    - Klonoar 1y ago
      No, I didn't. Did you even read my comment? I called out Flash. I could not have written a more straightforward note about how their comment was set up. Nothing I said indicated I disagree with their overall stance, just that Flash is a ridiculous thing to trot out.
danaris 1y ago
I mean, of course they can. They're Google. What are you going to do, stop using Chrome and searching with Google and using Gmail and buying AdWords and....etc? This is what happens when you have a monopoly.

dang 1y ago

Related ongoing thread: Should the web platform adopt XSLT 3.0? - https://news.ycombinator.com/item?id=44987552 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 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 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 https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)

scotty79 1y ago

I hope that if they decide to update XSLT they'll also implement this: https://en.wikipedia.org/wiki/Efficient_XML_Interchange https://en.wikipedia.org/wiki/Efficient_XML_Interchange

thro1 1y ago

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-3213412959 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.