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?
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...)
Yeah, I was surprised so many people were caring about XSLT. As a language it really isn't very good and I wasn't aware it was used in a meaningful fashion at all.
(Still, it always felt like a glimpse into an alternative, much less hackish processing model for the web, where you just have DOM trees and a pipeline of pure functions to transform them into different trees. I think that approach is still worth exploring and a lot of more recent tech, like React does it)
But I feel the backlash is more a symptom of how the web platform is ran in general.
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.
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.
> 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.
> 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.
I find it bizarre. I think we obviously we want to be able to run pages from 2015 far in the future but certainly for a few more years.
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?
How could #2 possibly be true without it being a deliberate choice on Google's part? They have staggering, absurd amounts of money. If they needed more resources allocated to Chrome, they could just do that.
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.
> HTML purists who do things without JS. They are the real web developers.
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
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 have yet to find a website which pleasantly lets me download a bunch of things in an efficient and organized manner that compares with FTP. The hilarity of buying a Humble Bundle and pressing "download all" and watching your browser spam "save as" windows for a minute and a half...
I kinda wish I could (S)FTP a lot more things than I can today.
FTP was not torn down just because some web browsers stopped also being FTP clients. You can still use any FTIP client with any FTP server that you want.
Firefox and Chromium had in-built FTP protocol handlers. I believe extensions could depend on this in such a way that the removal might break things for them, but general web content couldn’t—it was just an external link.
Safari and IE didn’t have integrated FTP: rather, they could hand FTP links over to the OS for something outside the browser to handle.
Now Firefox and Chromium can hand FTP over to the OS too.
XSLT, on the other hand, is integrated, a true part of the web platform. XSLTProcessor on any page, <?xml-stylesheet?> on XML files loaded directly… it works everywhere. The case is quite different from FTP.
If they remove XSLT, this will be the first time a major baseline-available feature has been removed. (One or two minor features have been removed: SharedArrayBuffer was temporarily dropped very shortly after landing across the board, for solid security reasons, taking up to 4 years to return with suitable limitations; and mutation events came in 2011 before quickly being replaced with mutation observers in 2012–2013, finally being removed in the last year or so; and the unload event which has been known to be unreliable and a bad idea for at least a decade is in the process of being removed. But all three of these are likely to be very minor in their effects, where XSLT removal just breaks your entire page.)
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.
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…
Interesting. Not a bad proposal, but am I reading correctly that partials from a different URL (“includes”) is a someday thing rather than part of the initial spec?
Either way it’d allow several types of sites to have zero dependencies and no build step which is pretty cool.
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.
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.
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.
Not at all. The existence of general purpose scripting isn't and shouldn’t be at odds with equipping HTML to handle a few very common, very basic tasks without JS. There’s plenty to be gained by doing so, including better ergonomics and efficiency. Even heavy JS apps stand to benefit since it’s that much less code to have to write and maintain.
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.
SameSite by default cookies come to mind: 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.
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.
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.
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?
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?
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.
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.
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.
> 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
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 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.
In this case there is the vocal minority who uses it, and then an even more vocal group who was just reminded XSLT even exists and is protesting its removal on vague ideological grounds. The proposal has clear mitigations for websites or use cases that depend on it, e.g. a WebAssembly polyfill.
The polyfill is a distraction; it does nothing for the use cases in the wild unless it's shipped with the browser, which is basically orthogonal to the spec and in any case Chrome was not willing to do.
I dont think the web assembly is a great polyfill, at least for the <?xml-stylesheet processing instruction. The better alternative is to just use CSS which is powerful enough for most real usecases.
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.
> 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.
> 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?
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.
The difference is for proprietary features, you can just charge that subset of users that care for its maintenance, using that money to hire additional developers, etc. For OSS you instead have a relatively fixed budget of time & resources and have to balance competing interests in a zero-sum manner. On the flip side, there's nothing preventing the vocal minority from forking if the feature is important enough to them!
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.
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.
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.
>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.
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.
XSLT is not going away. You can still use it no matter what happens (and it's far from certain something will happen). Browsers are still built on open standards. It just doesn't need to be bundled in every browser by default, similar to BMP as mentioned in the article.
"XSLT isn't a tool for surveillance capitalism, nor for glossy product brochure presentation, nor for captive passive doomscrolling video experiences, so it must be actively excised from the global knowledge network hypermedia standard"
If that's not saying "they're doing it because [..]" then I don't know what it's saying.
I made my point more clear in this later comment thread, in which we are talking, where I said:
> 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.
There is a long history of conflicts of interest in Web standards (de jure and de facto), and my point is that regardless of the merits of removing XSLT there's a big problem of the lack of credibility of some.
It's that history and credibility that is inviting impassioned pushback.
The dialogue makes a lot more sense once we realize the credibility problem.
If we ignore that credibility problem, we'll be banging our heads against the wall with how crazy the dialogue is.
Once we acknowledge the problem, we might be able to move forward, and perhaps even improve the root problem.
Okay, so you're saying these people have no credibility to their intentions, and you posit some nefarious alternative motivations for removing XSLT. But you're not saying these people (with no credibility to their intentions) are actually doing this for the alternative nefarious reasons that you mentioned. Ehh... like ... what?
You said what you said in that thread. And your "clarification" here adds little nuance to it.
I think there are two reasonable incompatible points of view at work here:
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.
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.
I think there's a fundamental misunderstanding of what standards are here.
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.
> A standard that's not implemented isn't worth anything
I agree, but this is not about that.
XSLT is implemented. Websites use it. I would argue the barrier to remove it should be incredibly high, not "we don't want to financially support the dude who maintains the library". Web standards should be close to permanent, which is why we should not add stupid ones left and right.
The problem I have in particular with how Google uses it's incredible clout to mismanage the web is it actively chips away at the web's stability. The goofiness the CA/B is up to is similar: Over 80% of organizations have outages every year due to certificate issues, and some absolutely clueless folks think 47 day certificate lifetimes is a good decision. The web in 2025 is incredibly fragile, and all signs lead to Google continuing to try to make it more fragile. You could pull in dozens of examples of centralizing forces that ensure one engineer pushing a bad configuration at one company takes down 40% of the web.
The Web is not Android. Apps on it should not break because you didn't submit a new version which updates to the latest platform framework within the last six months. Something on the web should, ideally, continue to work in perpetuity, unless acted on by an outside force (most likely by the site owner failing to continue paying the bill).
XSLT exists, it's supported by every major browser right now, and it should be nearly illegal to remove it.
The barrier is incredibly high. I'd be pretty surprised if this process takes less than five years because the bar is so high.
Also you keep saying "Google" and ignoring that all the vendors are tentatively in support of this. What if Olli had opened the issue? He raised it at WHATNOT.
Also, Mason is one if the nicest guys I know, and this is his job. I really don't think he's sad about a bunch of people misinterpreting what's going on and freaking out about it.
Some of what your saying could be confusion on the part of many people about what a standard is and isn't... And I think that while I don't necessarily agree that Google shouldn't be involved, I think this confusion is in the neighborhood of your concerns. It used to be much more the case, and indeed with other standards work it is the case, that a corporate entity was just another schmoe and people didn't necessarily have so much reflexive deference perhaps? Thank you for posting this honest opinion.
XSLT specifics? Yes, ubernerd ... Person who can't get a doctor's appointment because the interactive voice menu which is somehow now based on a browser engine and has a subtle bug caused by this change could be anyone.
Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)?
Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)
I have personally witnessed web technology related components in the critical path of complex enterprise insurance systems. Setting aside things like the whole of .NET being steeped in web browser components, and the added complexity of being forced to isolated these components by the court, things like Selenium are used for getting around integration and licensing problems. It isn't right, it isn't efficient, it will be a year long project to change them... We've already seen outages caused by XML engines dereferencing domains that aren't available anymore causing subtle and hard to find bugs. People don't realize that we built a lot of cool stuff on XML and semantic web stuff that all works and is all needed in various ways! It would not surprise me if web browser automation is not central to a ton of backend integration and automation for absolute sure.
Well they meant that I was conflating two things, and I was, because you can reference stylesheets to transform XML from one form to another, you can use it to render XML into HTML (or anything within limits), and that was the part that I was referring to specifically. That process can happen in a browser, on the command line, inside of Java dependency injection, build systems... It's in a lot of things because for what it is and what it can do it is pretty broadly applicable. It just isn't sexy front end or clear isolated backend so maybe that's the confusion here. I'm talking IBM, Oracle software acquired over decades from smaller companies that tried it all. And taking it out of a browser engine breaks these systems as well. A browser is used for testing, literal hack glue using tools like Selenium for systems integration, end users interacting with the system or administrators interacting with them... And again, some systems use browsers programmatically... XSLT is huge in mid 2000s report generation. The more I think about it, it does feel like a mini Y2K to touch the HTML rendering pipeline in this way. I think it could have subtle and hard to find consequences, and it doesn't feel extreme, maybe making a whole thread does about it though lol
The better phrased version of my criticism is that voice menus are generally not rendered using a web browser and thus deprecating xslt in web browsers cannot possibly affect them.
I mentioned it elsewhere but tons of enterprise backend automation and integration has web browsers and web browser components in the critical path, yes.
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.
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.)
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.
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.
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.
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.
The extreme arrogance on display from Google in the linked GitHub thread really makes me wish MS steps in to keep XSLT alive in Edge and more people switch away from Chrome.
Google: "We don't care. We don't have to." [1]
Browser diversity is a good thing, but we soon may be back to the days of "Best Viewed In Microsoft Internet Exporer"
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.
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?
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.)
Google isn't unilaterally removing XSLT from Chrome. They are participating in a discussion to remove it from the standards first. This would absolutely not be a Chrome-only thing, and so has nothing to do with Chrome marketshare. All the browser vendors are on board here.
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?
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
Yeah, I was surprised so many people were caring about XSLT. As a language it really isn't very good and I wasn't aware it was used in a meaningful fashion at all.
(Still, it always felt like a glimpse into an alternative, much less hackish processing model for the web, where you just have DOM trees and a pipeline of pure functions to transform them into different trees. I think that approach is still worth exploring and a lot of more recent tech, like React does it)
But I feel the backlash is more a symptom of how the web platform is ran in general.
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"
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.
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.
> 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.
> 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.
I find it bizarre. I think we obviously we want to be able to run pages from 2015 far in the future but certainly for a few more years.
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?
I wish there was a way to fund XSLT feature in browsers. Chrome team should just open up a funding for features page.
> Does it matter whether it will take three months or three years?
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?
> Since I suppose none of the browser vendors will give developers money to change their xslt usage in codebases for something else.
Let's turn that around: are you willing to pay a browser vendor to keep supporting xslt so you can keep your codebase unchanged?
How could #2 possibly be true without it being a deliberate choice on Google's part? They have staggering, absurd amounts of money. If they needed more resources allocated to Chrome, they could just do that.
This is addressed directly in the linked article. "Google" and "the Chrome team" are not the same entity.
Related ongoing thread:
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 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.
> HTML purists who do things without JS. They are the real web developers.
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.
> 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
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.
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.
I have yet to find a website which pleasantly lets me download a bunch of things in an efficient and organized manner that compares with FTP. The hilarity of buying a Humble Bundle and pressing "download all" and watching your browser spam "save as" windows for a minute and a half...
I kinda wish I could (S)FTP a lot more things than I can today.
Wget? Like this isn't a protocol issue but a website issue. You can do this sort of thing with http just fine.
Can you POST with wget? wput? I should know this...
The comment i was responding to was about download not upload.
Certainly though you can do multiple upload on a protocol level in http (resumable upload less so)
Afterall, S3 clients are all http under the hood, and that is basically the defacto standard now.
There certainly exists features in ftp not present in http, but they were rarely used/bad ideas (hello server to server transfer)
FTP was not torn down just because some web browsers stopped also being FTP clients. You can still use any FTIP client with any FTP server that you want.
But it was torn down from the browser. That’s what we are talking about with respect to XSLT
Firefox and Chromium had in-built FTP protocol handlers. I believe extensions could depend on this in such a way that the removal might break things for them, but general web content couldn’t—it was just an external link.
Safari and IE didn’t have integrated FTP: rather, they could hand FTP links over to the OS for something outside the browser to handle.
Now Firefox and Chromium can hand FTP over to the OS too.
XSLT, on the other hand, is integrated, a true part of the web platform. XSLTProcessor on any page, <?xml-stylesheet?> on XML files loaded directly… it works everywhere. The case is quite different from FTP.
If they remove XSLT, this will be the first time a major baseline-available feature has been removed. (One or two minor features have been removed: SharedArrayBuffer was temporarily dropped very shortly after landing across the board, for solid security reasons, taking up to 4 years to return with suitable limitations; and mutation events came in 2011 before quickly being replaced with mutation observers in 2012–2013, finally being removed in the last year or so; and the unload event which has been known to be unreliable and a bad idea for at least a decade is in the process of being removed. But all three of these are likely to be very minor in their effects, where XSLT removal just breaks your entire page.)
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.
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…
https://github.com/WICG/declarative-partial-updates
Interesting. Not a bad proposal, but am I reading correctly that partials from a different URL (“includes”) is a someday thing rather than part of the initial spec?
Either way it’d allow several types of sites to have zero dependencies and no build step which is pretty cool.
Remember shtml which was supposed to be server side include? It never made it to the web browser.
There is no point of introducing yet another standard to do something that can be done in few lines of JS.
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.That’s not nearly as nice as being able to drop a…
…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.We should drop HTML and CSS files as well, because you can just use JS to create DOM nodes and set styles on them.
One of the greatest features of pdf is that js support is unreliable.
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.
The point is to take JS implemented features and make them native to the browser.
That's a terrible point.
Not at all. The existence of general purpose scripting isn't and shouldn’t be at odds with equipping HTML to handle a few very common, very basic tasks without JS. There’s plenty to be gained by doing so, including better ergonomics and efficiency. Even heavy JS apps stand to benefit since it’s that much less code to have to write and maintain.
> 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
A/B testing the removal of a browser standard gives me pause. Is there precedent for that?
Yes, they've done it before. Some example:
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...
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.
SameSite by default cookies come to mind: 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.
They removed JXL support just when it was increasing popularity so it didn't interfere with their AVIF plans.
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.
Removing Flash, Mutation Events, and third-party cookies broke websites.
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.
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.
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?
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.
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.
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.
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.
> 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
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.
Here's a web archive: https://web.archive.org/web/20080220170805/https://wowarmory...
(dead_dove.gif)
Remember similar arguments were made not to support WebGL 2.0 Compute, also from Chrome team, because WebGPU was going to be much better.
I hope that if they decide to update XSLT they'll also implement this:
https://en.wikipedia.org/wiki/Efficient_XML_Interchange
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/
In this case there is the vocal minority who uses it, and then an even more vocal group who was just reminded XSLT even exists and is protesting its removal on vague ideological grounds. The proposal has clear mitigations for websites or use cases that depend on it, e.g. a WebAssembly polyfill.
The polyfill is a distraction; it does nothing for the use cases in the wild unless it's shipped with the browser, which is basically orthogonal to the spec and in any case Chrome was not willing to do.
I dont think the web assembly is a great polyfill, at least for the <?xml-stylesheet processing instruction. The better alternative is to just use CSS which is powerful enough for most real usecases.
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.
> 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.
> 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/
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.
The difference is for proprietary features, you can just charge that subset of users that care for its maintenance, using that money to hire additional developers, etc. For OSS you instead have a relatively fixed budget of time & resources and have to balance competing interests in a zero-sum manner. On the flip side, there's nothing preventing the vocal minority from forking if the feature is important enough to them!
> As opposed to non-OSS, where removing features that paying customers care about is of course trivial?
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.
I wish my career had entirely comprised of as functional of companies as you seem to work in.
Also: It deserved to die
Also also: You hope it burns in hell?
Also also also: Really sorry, it's Pavlovian.
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.
>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!
I clicked through to this comment section via HN RSS feeds.
I shot the sheriff, but I did not shoot XSLT.
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.
I think the problem is that people irrationally hate google the way slashdot irrationally hated micro$oft back in the day.
There is really no winning for them. They weren't even the party who proposed removing xslt.
Are you talking about Google as a whole?
> they operate in a self-serving echo chamber.
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.
[1]: https://news.ycombinator.com/item?id=44988418
>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.
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.
XSLT is not going away. You can still use it no matter what happens (and it's far from certain something will happen). Browsers are still built on open standards. It just doesn't need to be bundled in every browser by default, similar to BMP as mentioned in the article.
What do you think happened when HTML was introduced? Its not like html was the only thing trying to do hypertext documents. HTML just happened to win.
I didn't say that's why they were doing it.
Mate ... Your full comment:
"XSLT isn't a tool for surveillance capitalism, nor for glossy product brochure presentation, nor for captive passive doomscrolling video experiences, so it must be actively excised from the global knowledge network hypermedia standard"
If that's not saying "they're doing it because [..]" then I don't know what it's saying.
I made my point more clear in this later comment thread, in which we are talking, where I said:
> 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.
There is a long history of conflicts of interest in Web standards (de jure and de facto), and my point is that regardless of the merits of removing XSLT there's a big problem of the lack of credibility of some.
It's that history and credibility that is inviting impassioned pushback.
The dialogue makes a lot more sense once we realize the credibility problem.
If we ignore that credibility problem, we'll be banging our heads against the wall with how crazy the dialogue is.
Once we acknowledge the problem, we might be able to move forward, and perhaps even improve the root problem.
Okay, so you're saying these people have no credibility to their intentions, and you posit some nefarious alternative motivations for removing XSLT. But you're not saying these people (with no credibility to their intentions) are actually doing this for the alternative nefarious reasons that you mentioned. Ehh... like ... what?
You said what you said in that thread. And your "clarification" here adds little nuance to it.
[flagged]
[flagged]
[flagged]
I think there are two reasonable incompatible points of view at work here:
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.
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.
> they need to provide a clear venue for people to indicate whether or not the community is accepting of a change.
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.
I think there's a fundamental misunderstanding of what standards are here.
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.
> A standard that's not implemented isn't worth anything
I agree, but this is not about that.
XSLT is implemented. Websites use it. I would argue the barrier to remove it should be incredibly high, not "we don't want to financially support the dude who maintains the library". Web standards should be close to permanent, which is why we should not add stupid ones left and right.
The problem I have in particular with how Google uses it's incredible clout to mismanage the web is it actively chips away at the web's stability. The goofiness the CA/B is up to is similar: Over 80% of organizations have outages every year due to certificate issues, and some absolutely clueless folks think 47 day certificate lifetimes is a good decision. The web in 2025 is incredibly fragile, and all signs lead to Google continuing to try to make it more fragile. You could pull in dozens of examples of centralizing forces that ensure one engineer pushing a bad configuration at one company takes down 40% of the web.
The Web is not Android. Apps on it should not break because you didn't submit a new version which updates to the latest platform framework within the last six months. Something on the web should, ideally, continue to work in perpetuity, unless acted on by an outside force (most likely by the site owner failing to continue paying the bill).
XSLT exists, it's supported by every major browser right now, and it should be nearly illegal to remove it.
The barrier is incredibly high. I'd be pretty surprised if this process takes less than five years because the bar is so high.
Also you keep saying "Google" and ignoring that all the vendors are tentatively in support of this. What if Olli had opened the issue? He raised it at WHATNOT.
Also, Mason is one if the nicest guys I know, and this is his job. I really don't think he's sad about a bunch of people misinterpreting what's going on and freaking out about it.
Some of what your saying could be confusion on the part of many people about what a standard is and isn't... And I think that while I don't necessarily agree that Google shouldn't be involved, I think this confusion is in the neighborhood of your concerns. It used to be much more the case, and indeed with other standards work it is the case, that a corporate entity was just another schmoe and people didn't necessarily have so much reflexive deference perhaps? Thank you for posting this honest opinion.
> 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.
XSLT specifics? Yes, ubernerd ... Person who can't get a doctor's appointment because the interactive voice menu which is somehow now based on a browser engine and has a subtle bug caused by this change could be anyone.
Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)?
Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)
I have personally witnessed web technology related components in the critical path of complex enterprise insurance systems. Setting aside things like the whole of .NET being steeped in web browser components, and the added complexity of being forced to isolated these components by the court, things like Selenium are used for getting around integration and licensing problems. It isn't right, it isn't efficient, it will be a year long project to change them... We've already seen outages caused by XML engines dereferencing domains that aren't available anymore causing subtle and hard to find bugs. People don't realize that we built a lot of cool stuff on XML and semantic web stuff that all works and is all needed in various ways! It would not surprise me if web browser automation is not central to a ton of backend integration and automation for absolute sure.
You understand that XSLT isn't xml, right? This change will probably have a 0% impact on selenium or similar browser automation.
> You understand that XSLT isn't xml, right?
XSLT is XML, but XML isn't XSLT.
Well they meant that I was conflating two things, and I was, because you can reference stylesheets to transform XML from one form to another, you can use it to render XML into HTML (or anything within limits), and that was the part that I was referring to specifically. That process can happen in a browser, on the command line, inside of Java dependency injection, build systems... It's in a lot of things because for what it is and what it can do it is pretty broadly applicable. It just isn't sexy front end or clear isolated backend so maybe that's the confusion here. I'm talking IBM, Oracle software acquired over decades from smaller companies that tried it all. And taking it out of a browser engine breaks these systems as well. A browser is used for testing, literal hack glue using tools like Selenium for systems integration, end users interacting with the system or administrators interacting with them... And again, some systems use browsers programmatically... XSLT is huge in mid 2000s report generation. The more I think about it, it does feel like a mini Y2K to touch the HTML rendering pipeline in this way. I think it could have subtle and hard to find consequences, and it doesn't feel extreme, maybe making a whole thread does about it though lol
[flagged]
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
https://news.ycombinator.com/newsguidelines.html
That's fair.
The better phrased version of my criticism is that voice menus are generally not rendered using a web browser and thus deprecating xslt in web browsers cannot possibly affect them.
You can certainly use XSLT with https://www.w3.org/TR/voicexml20/ have you built software on any Linux platform? XSLT is required in so much stuff.
And did you render it in chrome?
Nobody is killing xslt in general, just the web browser bindings.
I mentioned it elsewhere but tons of enterprise backend automation and integration has web browsers and web browser components in the critical path, yes.
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.
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.
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.)
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.
People who want that feature to stay in the browsers should put up some money to fund continued development and maintenance.
The problem with this is that it incentivizes browsers to only implement features if it makes them money and to remove everything else.
Sure, but that's a different argument entirely - we don't have money vs you should be spending the money.
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.
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.
XSLT in the browser was always a bad idea.
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.
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.
The extreme arrogance on display from Google in the linked GitHub thread really makes me wish MS steps in to keep XSLT alive in Edge and more people switch away from Chrome.
Google: "We don't care. We don't have to." [1]
Browser diversity is a good thing, but we soon may be back to the days of "Best Viewed In Microsoft Internet Exporer"
[1] https://vimeo.com/355556831
Which comments did you see as being arrogant?
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.
Idk, this seems like pretty standard communications for a committee-driven process…
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?
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.)
Google isn't unilaterally removing XSLT from Chrome. They are participating in a discussion to remove it from the standards first. This would absolutely not be a Chrome-only thing, and so has nothing to do with Chrome marketshare. All the browser vendors are on board here.
MS doesn't even make a browser engine.