Seems like a pretty cut and dried case for removal of a feature that is not only not used but even in cases where it might be useful the sites have html versions and don't expect people to click on the xml links.
Browser vendors really screwed the pooch on XSLT, the same way that MNG got sidelined in the past. They integrated an early version of a tech and then completely failed to modernize it.
There's potentially a real need for something like XSLT + XForms for low-to-no JS interactivity.
Even a basic JS-free, HTML-modifying operation for WebForms would go a long way towards that (ie: insert a row, delete an element matching this ID on click), etc.
Frankly I think this is a tempest in a teapot, and the primary reason people are complaining is because Google is sponsoring the idea, not because it's going to harm users in some tangible way.
I'm totally sure the discussion on the github issue is nothing but civil and not at all filled with righteous keyboard warriors decrying the evils of mustache-twiddling corporate villains out to destroy the web...
One thing that I think this discussion is highlighting to me is that there's very little support in the web standard (as implemented by browsers) for surfacing resources to users that aren't displayable by the browser.
Consider, for example, RSS/Atom feeds. Certainly there are <link /> tags you can add, but since none of the major browsers do anything with those anymore, we're left dropping clickable links to the feeds where users can see them. If someone doesn't know about RSS/Atom, what's their reward for clicking on those links? A screenful of robot barf.
These resources in TFA are another example of that. The government or regulatory bodies in question want to provide structured data. They want people to be able to find the structured data. The only real way of doing that right now is a clickable link.
XSLT provides a stopgap solution, at least for XML-formatted data, because it allows you to provide that clickable, discoverable link, without risking dropping unsuspecting folks straight into the soup. In fact, it's even better than that, because the output of the XSLT can include an explainer that educates people on what they can do with the resource.
If browsers still respected the <link /> tag for RSS/Atom feeds, people probably wouldn't be pushing back on this as hard. But what's being overlooked in this conversation is that there is a real discoverability need here, and for a long time XSLT has been the best way to patch over it.
but why priviligize XML? there's WASM and sites can have any kinds of codecs they want.
unfortunately(?) modern browsers are turning more into these sandbox and state managers with a few lower-level rendering engines bolted together (JS driving the DOM, plus CSS and SVG and audio and video and font and various image codecs and ...)
and if people want to copy the raw data URL the site can show them, plus HTTP provides the Accept and other headers for content negotiation so in theory the URL can be the same.
Why is it better to drop users onto the RSS page and say copy the URL in the address bar, rather than just giving a copy button that puts it on the clipboard and say put this in your RSS app?
Flash removal broke multiple government sites. I couldn't take a required training course for a few months after flash support was removed and the site was taken offline for an upgrade.
I’m sure ActiveX and Silverlight removal did too. And iframes not sharing cross domain cookies. And HTTP mixed content warnings. I get it, some of these are not web specs, but some were much more popular than XSLT is now.
The government will do what they do best, hire a contractor to update the site to something more modern. Where it will sit unchanged until that spec too is removed, some years from now.
I don't understand how WHATWG decides to remove XSLT, contradicting the 30+ years of never break the web doctrine... And simultaneously doesn't want to fix the typeof null specification bug because of, wait for it, Microsoft Exchange 2003 relying on that.
This makes absolutely no sense.
We could've had such a nice language. The efforts for a cleaner language and web platform API were there, but doctrine always said no because of legacy and people have moved on to alternatives now.
What is the typeof null specification bug? You mean that typeof null === 'object'? That's not a bug. It's also not WHATWG's responsibility, it's part of ECMAScript.
Here are some of the common sense rules for evolving a standard:
1. Keep the standards simple. Avoid adding features if you can. Standards define implementations. Don't invert that pattern and make the standards morbidly obese.
2. Keep the features orthogonal. Don't create multiple ways of doing the same thing. Make sure that each feature plays well with the the others.
3. Maintain backwards compatibility. Don't break anything that depends on your standard. Don't frustrate your implementers and their customers with an endless game of whack-a-mole.
4. All the above are on a best-effort basis. Exceptions are acceptable under exceptional circumstances.
For some reason, the WHATWG has the diametrically opposite belief on all the above. Perhaps they should be called the Web upside-down standards. You have no problem adding features to the standards faster than anyone can read it. But maintaining and upgrading an old feature is somehow too far beyond your capability to justify keeping it around. I guess it's back to uni for me to figure out how I got this so wrong.
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.
Removals sometimes take a decade or more, or sometimes don't happen at all. Just because the vendors would like to remove something, doesn't mean they can.
For example, MutationEvents were deprecated in 2011 and just removed last year.
So this is just the beginning of the process. Even the PR to remove XLST from the spec: it doesn't mean it's being merged soon. Removal from the spec is different from remove from engines.
Honestly, I hope they remove it. And I hope they remove more pointless/useless standards kept around for backward compatibility, it's the anthesis of progress. We cannot keep loading the browser with more and more standards forever, either we stop development or we begin to remove things.
"Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?" - Alan Perlis
I used to use XSLT all the time, but I had forgotten all about and haven't used it in years. It was perfect to do a quick SQL query with "for xml auto" and then add an XSLT stylesheet to it. Instant report.
xml + xslt should never have been allowed client side. not sure why no one decided to force this as a server side operation, or at least require it to be done in js.
BUT since it's there, don't take it out, or at least take it out of the spec and then require all browser vendors to auto-install a plugin that re-performs the missing feature, and warn that this page relies on a plugin or something
Is there a reason this can't move into an extension? It seems like JS in the browser could implement rendering. I think simplifying the standard makes sense.
They should switch, then. This notion that we can't peal away browser spec complexity because it will break some websites is the same reason ActiveX continued to wreck havoc long after it should have. I found multiple security vulnerabilities in XSLT back in my pen-testing days, and even if it didn't increase the threat surface, browser spec needs to be simplified anyway.
XML and XSLT: an elegant tool for a more civilized age. Anything that came later was worse: YAML and JSON; while dark forces bastardized XML and silently killed XHTML.
See if you parse an HTML page these days - heck, if you're lucky Anubis girl will let you in and see the javascript trash soup, maybe even taste it.
By the way I just noticed the JSON embedded viewer has disappeared from Firefox and Chrome?
The XML viewer is still there, there are colors and you can collapse the nodes.
XML was an abomination in terms of format but there were some really good ideas in the early web. I remember you could point to a stylesheet to apply to an XML file.
I really wish we could apply CSS stylesheets to a JSON.
I have no personal interest in whether XSLT is supported in browsers. I've never once used it as a developer, but it doesn't offend my sensibilities to keep it around. To me, finding out that XSLT may be removed from the standard was like finding out that Fortran was being removed: huh, that was in there?
But as a meta comment, I'm surprised at the number of strong emotions on either side of this. I refused to believe that so many people knew or cared that XSLT was an existing feature in browsers before this all came up. And the hyperbole behind "this destroys the open web" blow my mind. I've been writing HTML since the mid 90s, and although I've known what XSLT is all along, I've never been in the room with anyone who claimed that they used it for any reason whatsoever.
Regardless of what happens, this is not the death of the open web. I have no doubt that certain people depend on having it in browsers, but there's no way it's required by more than a tiny portion of websites. Yes, this will be inconvenient and possibly expensive for those sites, and I am sympathetic to them. But the web? It's gonna be just fine without it, should that come to pass.
30 comments
[ 3.1 ms ] story [ 46.7 ms ] threadThere's potentially a real need for something like XSLT + XForms for low-to-no JS interactivity.
Even a basic JS-free, HTML-modifying operation for WebForms would go a long way towards that (ie: insert a row, delete an element matching this ID on click), etc.
https://github.com/whatwg/html/issues/11582#issuecomment-321...
Frankly I think this is a tempest in a teapot, and the primary reason people are complaining is because Google is sponsoring the idea, not because it's going to harm users in some tangible way.
Consider, for example, RSS/Atom feeds. Certainly there are <link /> tags you can add, but since none of the major browsers do anything with those anymore, we're left dropping clickable links to the feeds where users can see them. If someone doesn't know about RSS/Atom, what's their reward for clicking on those links? A screenful of robot barf.
These resources in TFA are another example of that. The government or regulatory bodies in question want to provide structured data. They want people to be able to find the structured data. The only real way of doing that right now is a clickable link.
XSLT provides a stopgap solution, at least for XML-formatted data, because it allows you to provide that clickable, discoverable link, without risking dropping unsuspecting folks straight into the soup. In fact, it's even better than that, because the output of the XSLT can include an explainer that educates people on what they can do with the resource.
If browsers still respected the <link /> tag for RSS/Atom feeds, people probably wouldn't be pushing back on this as hard. But what's being overlooked in this conversation is that there is a real discoverability need here, and for a long time XSLT has been the best way to patch over it.
unfortunately(?) modern browsers are turning more into these sandbox and state managers with a few lower-level rendering engines bolted together (JS driving the DOM, plus CSS and SVG and audio and video and font and various image codecs and ...)
and if people want to copy the raw data URL the site can show them, plus HTTP provides the Accept and other headers for content negotiation so in theory the URL can be the same.
"Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 - Aug 2025 (522 comments)
Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
I’m sure ActiveX and Silverlight removal did too. And iframes not sharing cross domain cookies. And HTTP mixed content warnings. I get it, some of these are not web specs, but some were much more popular than XSLT is now.
The government will do what they do best, hire a contractor to update the site to something more modern. Where it will sit unchanged until that spec too is removed, some years from now.
This makes absolutely no sense.
We could've had such a nice language. The efforts for a cleaner language and web platform API were there, but doctrine always said no because of legacy and people have moved on to alternatives now.
What is the typeof null specification bug? You mean that typeof null === 'object'? That's not a bug. It's also not WHATWG's responsibility, it's part of ECMAScript.
1. Keep the standards simple. Avoid adding features if you can. Standards define implementations. Don't invert that pattern and make the standards morbidly obese.
2. Keep the features orthogonal. Don't create multiple ways of doing the same thing. Make sure that each feature plays well with the the others.
3. Maintain backwards compatibility. Don't break anything that depends on your standard. Don't frustrate your implementers and their customers with an endless game of whack-a-mole.
4. All the above are on a best-effort basis. Exceptions are acceptable under exceptional circumstances.
For some reason, the WHATWG has the diametrically opposite belief on all the above. Perhaps they should be called the Web upside-down standards. You have no problem adding features to the standards faster than anyone can read it. But maintaining and upgrading an old feature is somehow too far beyond your capability to justify keeping it around. I guess it's back to uni for me to figure out how I got this so wrong.
It's incorrect to say there are no removals, as we do not have <MARQUEE> anymore.
Removals sometimes take a decade or more, or sometimes don't happen at all. Just because the vendors would like to remove something, doesn't mean they can.
For example, MutationEvents were deprecated in 2011 and just removed last year.
So this is just the beginning of the process. Even the PR to remove XLST from the spec: it doesn't mean it's being merged soon. Removal from the spec is different from remove from engines.
"Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?" - Alan Perlis
BUT since it's there, don't take it out, or at least take it out of the spec and then require all browser vendors to auto-install a plugin that re-performs the missing feature, and warn that this page relies on a plugin or something
See if you parse an HTML page these days - heck, if you're lucky Anubis girl will let you in and see the javascript trash soup, maybe even taste it.
The XML viewer is still there, there are colors and you can collapse the nodes.
XML was an abomination in terms of format but there were some really good ideas in the early web. I remember you could point to a stylesheet to apply to an XML file.
I really wish we could apply CSS stylesheets to a JSON.
For example, I use it add an explanation of what RSS is and some styling to the RSS feed of my personal website [1].
[1]: https://vstollen.me/atom.xml
But as a meta comment, I'm surprised at the number of strong emotions on either side of this. I refused to believe that so many people knew or cared that XSLT was an existing feature in browsers before this all came up. And the hyperbole behind "this destroys the open web" blow my mind. I've been writing HTML since the mid 90s, and although I've known what XSLT is all along, I've never been in the room with anyone who claimed that they used it for any reason whatsoever.
Regardless of what happens, this is not the death of the open web. I have no doubt that certain people depend on having it in browsers, but there's no way it's required by more than a tiny portion of websites. Yes, this will be inconvenient and possibly expensive for those sites, and I am sympathetic to them. But the web? It's gonna be just fine without it, should that come to pass.