XSLT removal will break multiple government and regulatory sites
104 comments
·August 22, 2025jdpage
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.
jauntywundrkind
> 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.
Really wish registerProtocolHandler were more popular. And I really wish registerContentType hadn't been dropped!
Web technology could be such a nexus of connectivity. We could have the web interacting with so much, offering tools for so much. Alas, support has largely gotten worse decade by decade. And few have taken up the chance.
Bluesky is largely using at:// urls. Eventually we probably could argue for support for our protocol. But web+at:// is permission less. Tools like https://pdsls.com can just become web based tools, with near no effort, if they want.
fabrice_d
at:// urls were unfortunately mis-designed as explained in https://github.com/bluesky-social/atproto-website/issues/417
rhdunn
The suggestion to move the RSS/Atom feed links to a hidden link element is a horrible one for me and presumably others who want to copy that and paste it into their podcast applications. With that suggestion it adds another layer of indirection an application has to fetch and inspect.
Part of the reason HTML 5/LS was created was to preserve the behaviour of existing sites and malformed markup such as omitting html/head/body tags or closing tags. I bet some of those had the same usage as XSLT on the web.
jdpage
You're right, it's not a great flow! And while many podcast/feed reader applications support pasting the URL of the page containing the <link /> element, that still leaves the problem of advertising that one can even do that, or that there's a feed available in the first place.
01HNNWZ0MV43FF
> If someone doesn't know about RSS/Atom, what's their reward for clicking on those links? A screenful of robot barf.
The microformats folks have a standard to embed machine-readable feed data into HTML, which seems a lot more practical to me after seeing how browser just ignore RSS:
https://microformats.org/wiki/h-feed
(I haven't tried it but it seems fine)
caleblloyd
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.
ekianjo
Flash was never a web standard. XLST is.
null
spankalee
What's the practical different to users and site maintainers?
dlachausse
Maybe I'm missing something here, but can't XSLT be processed server side instead of browser side?
It seems like a very easy fix for the handful of websites that still use it.
ruined
XSLT is often used on low-power IOT devices which don't have the resources to render server-side
goku12
RSS/Atom feeds can use them. How does it make sense to maintain two versions of the same data on the server?
ryoshu
There are no easy fixes for government sites.
lp0_on_fire
There would be no reason to fix this if the chrome people had kept up their end of the bargain by supporting the standard. We can quibble as to whether or not XSLT should have been part of the standard to begin with but it IS part of the standard.
Google says it's "too difficult" and "resource intensive" to maintain...but they've deliberately left that part of the browser to rot instead of incrementally upgrading it to a modern XSLT standard as new revisions were released so it seems like a problem of their own making.
Given their penchant for user-hostile decisions it's hard to give the chrome team the benefit of the doubt here that this is being done purely for maintainability and for better security (especially given their proposal of just offloading it to a js polyfill).
cookiengineer
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.
spankalee
Easy: The WHAATWG hasn't decided to remove XLST. They are starting the process of deciding now.
bazoom42
WHATWG have removed features before, e.g. frameset, font, and applet elements from HTML. All of them were rarely used and had better alternatives available.
troupo
> WHATWG have removed features before, e.g. frameset, font, and applet elements from HTML.
font: supported in all browsers https://caniuse.com/?search=font
frameset: supported in all browsers https://caniuse.com/?search=frameset
applet: supported in all browsers https://caniuse.com/?search=applet
> All of them were rarely used and had better alternatives available.
"Rarely used" is not enough of a justification
ioasuncvinvaer
So a feature was removed from the spec and it is still supported. I don't see how it would be bad to remove XSLT then?
masklinn
Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that (pretty sure every browser uses libxslt).
em-bee
pretty sure every browser uses libxslt
apparently firefox has their own implementation. not that that makes things any better. the firefox implementation appears to be just as bad in shape as the libxslt bindings in chrome. see here for more details: https://news.ycombinator.com/item?id=44910050
mmastrac
It really should just be compiled to WASM and used with some sort of DOM bridge.
ioasuncvinvaer
The google people provided exactly that. A WASM polyfill.
masklinn
The big sticking point is not the JS access, that’s mildly easy to implement.
It’s that currently you can open an XML file (including feeds) with an associated stylesheet and the stylesheet gets applied, which can be used to render an HTML document on the client side from an xml source like a feed.
troupo
> Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that
And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth, WebKitchenSink, most of which have as much usage as XSLT: https://chromestatus.com/metrics/feature/timeline/popularity... or https://chromestatus.com/metrics/feature/timeline/popularity...
cookiengineer
This is actually a great point.
I was checking for XSLTProcessor out of curiosity, and most of the top sites seem to be all using Flarum as a software?
Found it a nice fun fact: https://chromestatus.com/metrics/feature/timeline/popularity...
If you check it though what they're using XSLTProcessor for, it seems to be a fallback for an MSXML polyfill, e.g. when you search for "XSLTProcessor" here you can see it: view-source:http://discuz.turzx.com/assets/forum.js?v=3c534b8a
So in the case of Flarum their DOMParser using alternative would chime in, as that's an additional fallback to the MSXML / ActiveX using polyfill.
dang
Recent and related:
"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)
kstrauser
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.
mmastrac
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.
eyelidlessness
Context: until fairly recently, I worked an implementation of XForms (as the project creator, and leading most of the architecture/design). Prior to that, I inherited maintenance of another implementation, which utilized XSLT[1] as a core aspect of its design.
I’m curious if you could describe more about what you envision. I have a difficult time imagining:
1. How the stateful/interactive aspects of XForms (such as insert/delete, as you mention) would be implemented client side without JS.
2. How XSLT factors into that vision.
It might be lack of imagination on my part! Admittedly, I don’t know everything about XSLT and maybe it has more interactive capabilities than I’m aware of. But at least as far as I know, when a browser vendor did implement XForms functionality it still ultimately depended on JS to achieve certain behaviors. It’s been a while since I was looking into this, but IIRC it looked conceptually similar to XUL. And granted, that might mean the JS is provided by a browser, and encapsulated from user space similar to browsers’ use of shadow DOM for standard form controls now.
1: I also have good reason to believe my work on this prior project helped keep XSLT alive in Chrome the last time there was a major push to deprecate it! Albeit totally inadvertently: my work just happened to correlate very closely to a spike in usage metrics around the same time, which was then cited as a reason to hold off on deprecation.
mmastrac
Even the most basic style of interaction would be amazing:
1. Associate a form element with a non-JS action, ie: add-element, remove-element, modify-element.
2. Allow those actions to make use of <template> elements when adding or modifying elements, and/or XPath selectors.
3. Add a new <input type=id> (or similar) that auto-generates unique UUIDs for form rows.
A mockup of what we'd get, though it's actually focused on pure HTML (it would be XML-compatible, however). This is 100% a straw-man, probably not even fully-self-consistent, but giving an idea of what I would want:
<h1>Declarative Form Example</h1>
<form action="/update" method="post">
<table id="people">
<thead>
<tr>
<th>First</th><th>Last</th><th>Email</th><th></th>
</tr>
</thead>
<tbody>
<!-- rows appear here -->
</tbody>
</table>
<button type="submit">Save</button>
</form>
<template id="row-template">
<tr data-row data-row-id data-bind:dataset(rowId)="row_id">
<td data-bind:text="first"><input type="hidden" name="first"><input type="uuid" name="row_id" autogenerate></td>
<td data-bind:text="last"><input type="hidden" name="last"></td>
<td>
<a data-bind:attr(href)="email_link" data-bind:text="email"></a>
<input type="hidden" name="email"><input type="hidden" name="email_link">
</td>
<td>
<button formmutate="remove"
formtarget='tr[data-row-id="{{row_id}}"]'
aria-label="Remove row"></button>
</td>
</tr>
</template>
<form id="add-person">
First <input name="first" required>
Last <input name="last" required>
Email <input name="email" type="email" required>
<input type="hidden" name="email_link" value="mailto:{{email}}">
<button formmutate="add" formtarget="#people > tbody" formtemplate="#row-template">Add</button>
</form>
- https://html.spec.whatwg.org/multipage/scripting.html#the-te...
- (defunct) https://html.spec.whatwg.org/multipage/form-elements.html#th...
rand17
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.
vstollen
One (admittedly niche) use case for XSLT is that it’s the only way I found to make RSS feeds both understandable for humans and machines.
For example, I use it add an explanation of what RSS is and some styling to the RSS feed of my personal website [1].
ptx
What about content negotiation [1] based on the Accept header? If the client indicates a preference for HTML you could send it the human-readable page and otherwise you send the RSS feed. Wouldn't that work?
[1] https://httpd.apache.org/docs/current/en/content-negotiation...
lucumo
If you read the first comment, it seems that these examples were cherry-picked alternative formats. Trying to drum up outrage, I guess.
I don't care one way or the other about XSLT, but fucking hell, I would like a boatload more intellectual honesty in the world. Being angry is not a good reason to cherry-pick your data. It is a reason to step away from the argument and cool down before you re-engage with honesty and clarity.
null
hateful
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.
spullara
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.
bryanrasmussen
I'm not sure I understand -
did you mean:
it 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) because it will break many government sites?
or
it 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) because the feature is not used etc. etc. ?
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.