8 ms·

XSLT removal will break multiple government and regulatory sites

160 points by colejohnson66 1y ago

spullara 1y ago
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 1y ago
  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. ?
jstanley 1y ago
Governments don't seem to be paying particular attention to which web sites they're killing, I don't see why we should provide them the courtesy.
- goku12 1y ago
  How did this become a case of us vs them? Government websites are meant for our benefit.
mmastrac 1y ago
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 1y ago
  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 1y ago
    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>  </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> Some existing standards/specs/proposals I cribbed this from: - https://html.spec.whatwg.org/multipage/scripting.html#the-template-element https://html.spec.whatwg.org/multipage/scripting.html#the-te... - (defunct) https://html.spec.whatwg.org/multipage/form-elements.html#the-output-element https://html.spec.whatwg.org/multipage/form-elements.html#th...
otterley 1y ago
This is a fair response to the point: https://github.com/whatwg/html/issues/11582#issuecomment-3215101504 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.
- fridek 1y ago
  I've got to admire Mason's chill in actually giving concrete replies to what are mostly ad-hominem attacks around this issue.
  - shortstuffsushi 1y ago
    No kidding, the entire thread seems to be "you don't know what you're doing and you haven't done any research," in the face of responses saying "correct, this is the beginning of the process, where we do the research." Then some random tag on guy presumably after this hit HN "I like that it doesn't have ads," which has literally nothing to do with the issue, lol.
  - lelandfe 1y ago
    I dunno, my snarkometer is going off. > Thanks for raising these 6 examples of sites publishing XML files. We can add it to the existing list of 357 sites This feels like an email I'd get from HR. The point of the topic was the ease in finding those 6, not to discuss those 6 specifically. Maybe being direct pisses people off more than this corporate-styled language, though.
    - otterley 1y ago
      I think he's responding to the fact that someone felt the need to create a new issue instead of attaching the information to the existing issue. It makes managing the work more difficult.
      - Arnavion 1y ago
chuckadams 1y ago
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...
- otterley 1y ago
  > righteous keyboard warriors Worst comic ever!
lucumo 1y ago
[flagged]
- deleted 1y ago
  [deleted]
whimsicalism 1y ago
i’m strongly in favor of simplifying the standard
jdpage 1y ago
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.
- rhdunn 1y ago
  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 1y ago
    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.
dang 1y ago
Recent and related: "Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 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 https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
caleblloyd 1y ago
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 1y ago
  Flash was never a web standard. XLST is.
  - _mlbt 1y ago
    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.
    - ryoshu 1y ago
      There are no easy fixes for government sites.
    - goku12 1y ago
      RSS/Atom feeds can use them. How does it make sense to maintain two versions of the same data on the server?
      - palsecam 1y ago
        Exactly. The Atom feed of my website declares an XSLT stylesheet which transforms it to HTML. That way it can be served directly to, and renders prettily by, a web browser (see https://paul.fragara.com/feed.xml https://paul.fragara.com/feed.xml). For the curious, the XLST can be found here: https://gitlab.com/PaulCapron/paul.fragara.com/-/blob/master/src/atom2html.xsl https://gitlab.com/PaulCapron/paul.fragara.com/-/blob/master... Btw, you can also apply an XSLT sheet to an XML document using standard JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcess...
6510 1y ago
It's great for admin areas.
cookiengineer 1y ago
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.
- masklinn 1y ago
  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).
  - mmastrac 1y ago
    It really should just be compiled to WASM and used with some sort of DOM bridge.
    - masklinn 1y ago
      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.
    - ioasuncvinvaer 1y ago
      The google people provided exactly that. A WASM polyfill.
      - youngtaff 1y ago
        Not really… it needs a HTML to load the polyfill and transform the XML You can’t have the browser load an XML file and have it transformed automatically as happens now
goku12 1y ago
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.
miohtama 1y ago
You can polyfill this with JavaScript though? It's incorrect to say there are no removals, as we do not have <MARQUEE> anymore.
- frosted-flakes 1y ago
  Yes we do. https://caniuse.com/mdn-html_elements_marquee https://caniuse.com/mdn-html_elements_marquee The marquee element is deprecated but is supported by all major Web browsers.
- ksherlock 1y ago
  With xml/xslt, the browser fetches, eg, somefile.xml that looks like: <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="somefile.xsl"?> ... Then the browser fetch somefile.xsl and uses that to transform the xml into html (which is then rendered as per the uzhe). Whether the browser does all that in C or C++ or Rust or Javascript or by sending it to an LLM is an implementation detail. If the browser drops xslt support and just displays it as text (or syntax-hilighted xml), I, as the xml author, can't polyfill that by adding javascript to the xml because it won't be executed. You need to back up a level. You could set up a web page that fetches the xml and fetch the xslt and transforms it into html and then displays it (so a browser in your browser so you can browse while you browse) but I wouldn't call that a polyfill exactly. If you're going to do that, it would be less work and a better user experience to do the transform server side.
  - Izkata 1y ago
    Webservers can push CSS through headers, I wonder if that works with javascript too...
  - 8NNTt8z3QvLT8tp 1y ago
    https://github.com/mfreed7/xslt_polyfill/pull/5 https://github.com/mfreed7/xslt_polyfill/pull/5 - someone's made a PR that looks like it would allow Mason's polyfill to work directly from the XML file.
_bzuf 1y ago
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.
spankalee 1y ago
Brian's comment here is really important for bystanders to be able to understand the process: https://github.com/whatwg/html/issues/11582#issuecomment-3207518017 https://github.com/whatwg/html/issues/11582#issuecomment-320... 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.
samdoesnothing 1y ago
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
hateful 1y ago
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.
throwmeaway222 1y ago
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
arjie 1y ago
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.
paulvnickerson 1y ago
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.
- troupo 1y ago
  > This notion that we can't peal away browser spec complexity They are not peeling away browser complexity. They revel in browser complexity. They gleefuly make browser as complex as possible.... as long as their promotions depend on it: https://news.ycombinator.com/item?id=44989576 https://news.ycombinator.com/item?id=44989576
  - kstrauser 1y ago
    None of those could be implemented in JavaScript or WASM. XSLT could. Say what you will about the popularity of each of them, but they can't exist without browser implementations. XSLT can be replaced with a polyfill.
    - youngtaff 1y ago
      > XSLT can be replaced with a polyfill Show me how a polyfill allows me to type https://example.com/rss.xml https://example.com/rss.xml in the URL bar and have it transformed to HTML in the browser?
      - kstrauser 1y ago
        I don’t think I’ve ever wanted to read an RSS feed directly, although I subscribe to a lot of them. Is that a popular reading method?
        troupo 1y ago
        It's a popular presentation format for RSS feeds. And you don't need to somehow attach a Javascript polyfill to an XML feed to make it readable for humans
rand17 1y ago
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.
sunshine-o 1y ago
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.
- Telemakhos 1y ago
  > I remember you could point to a stylesheet to apply to an XML file. You still can. That's exactly what this article is about: XSLT is that stylesheet. You can publish XML-structured data that machines can ingest, and you can attach XSLT to that data so that humans can view the exact same file in a human-friendly way. The browser constructs, according to the XSL transform rules, a Document Object Model out of the XML, and then it usually applies CSS to that DOM. No duplication of files, no "click here to get to the actual data." I've got some OPML (lists of podcasts) and RSS (podcast) XML files that are also human-readable web pages thanks to this; the exact same web address works for your favorite podcast app and for human viewing. > I really wish we could apply CSS stylesheets to a JSON. I don't think what you want is CSS in the first instance, but in the second: first you'd want a template transformation language like XLST is for XML. You'd want to be able to say not just "show these values in this font" but "for each key matching this pattern, create a DOM element containing that key, then another element containing its value," and then style them with CSS when a whole document has been generated out of the JSON. XML with XSLT almost always also included CSS to handle fonts and whatnot.
  - sunshine-o 1y ago
    Oh no you can apply a CSS directly to XML https://www.w3.org/Style/styling-XML.en.html https://www.w3.org/Style/styling-XML.en.html It is simple and works very well for simple documents. Remember, XHTML was just an XML document.
vstollen 1y ago
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]. [1]: https://vstollen.me/atom.xml https://vstollen.me/atom.xml
- ptx 1y ago
  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.html https://httpd.apache.org/docs/current/en/content-negotiation...
  - trekz 1y ago
    It can be done but it's not practical because most RSS readers don't even send an Accept header at all, let alone one with an XML mime type.
    - ptx 1y ago
      But browsers do send the Accept header, so you could default to RSS for requests from other clients (such as RSS readers).
kstrauser 1y ago
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.
chews 1y ago
Booze Allen Hamilton contractors be salivating at the mouth.
thro1 1y ago
> The real reason for the removal is that Google, a profit seeking corporation, considers XSLT to be unprofitable. > Of course, they can't say this out loud, so they instead have @mfreed7 cherry-pick some numbers as justification. ( https://github.com/whatwg/html/issues/11582#issuecomment-3215101504 https://github.com/whatwg/html/issues/11582#issuecomment-321... ) Mason Freed (mfreed7), XSLT, 2025, Jorge Villalobos, 'legacy' Firefox extensions, 2017, ..Mitchell Baker, ..Peter Daszak never will be forgotten for years of programmers lives lost and the pain they causing.

160 points by colejohnson66 1y ago

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 1y ago
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. ?

jstanley 1y ago

Governments don't seem to be paying particular attention to which web sites they're killing, I don't see why we should provide them the courtesy.

goku12 1y ago
How did this become a case of us vs them? Government websites are meant for our benefit.

mmastrac 1y ago

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 1y ago
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 1y ago
  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>  </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> Some existing standards/specs/proposals I cribbed this from: - https://html.spec.whatwg.org/multipage/scripting.html#the-template-element https://html.spec.whatwg.org/multipage/scripting.html#the-te... - (defunct) https://html.spec.whatwg.org/multipage/form-elements.html#the-output-element https://html.spec.whatwg.org/multipage/form-elements.html#th...

otterley 1y ago

This is a fair response to the point: https://github.com/whatwg/html/issues/11582#issuecomment-3215101504 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.

fridek 1y ago
I've got to admire Mason's chill in actually giving concrete replies to what are mostly ad-hominem attacks around this issue.
- shortstuffsushi 1y ago
  No kidding, the entire thread seems to be "you don't know what you're doing and you haven't done any research," in the face of responses saying "correct, this is the beginning of the process, where we do the research." Then some random tag on guy presumably after this hit HN "I like that it doesn't have ads," which has literally nothing to do with the issue, lol.
- lelandfe 1y ago
  I dunno, my snarkometer is going off. > Thanks for raising these 6 examples of sites publishing XML files. We can add it to the existing list of 357 sites This feels like an email I'd get from HR. The point of the topic was the ease in finding those 6, not to discuss those 6 specifically. Maybe being direct pisses people off more than this corporate-styled language, though.
  - otterley 1y ago
    I think he's responding to the fact that someone felt the need to create a new issue instead of attaching the information to the existing issue. It makes managing the work more difficult.
    - Arnavion 1y ago

chuckadams 1y ago

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

otterley 1y ago
> righteous keyboard warriors Worst comic ever!

lucumo 1y ago

[flagged]

deleted 1y ago
[deleted]

whimsicalism 1y ago

i’m strongly in favor of simplifying the standard

jdpage 1y ago

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.

rhdunn 1y ago
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 1y ago
  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.

dang 1y ago

Recent and related: "Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 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 https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)

caleblloyd 1y ago

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 1y ago
Flash was never a web standard. XLST is.
- _mlbt 1y ago
  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.
  - ryoshu 1y ago
    There are no easy fixes for government sites.
  - goku12 1y ago
    RSS/Atom feeds can use them. How does it make sense to maintain two versions of the same data on the server?
    - palsecam 1y ago
      Exactly. The Atom feed of my website declares an XSLT stylesheet which transforms it to HTML. That way it can be served directly to, and renders prettily by, a web browser (see https://paul.fragara.com/feed.xml https://paul.fragara.com/feed.xml). For the curious, the XLST can be found here: https://gitlab.com/PaulCapron/paul.fragara.com/-/blob/master/src/atom2html.xsl https://gitlab.com/PaulCapron/paul.fragara.com/-/blob/master... Btw, you can also apply an XSLT sheet to an XML document using standard JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcess...

6510 1y ago

It's great for admin areas.

cookiengineer 1y ago

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.

masklinn 1y ago
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).
- mmastrac 1y ago
  It really should just be compiled to WASM and used with some sort of DOM bridge.
  - masklinn 1y ago
    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.
  - ioasuncvinvaer 1y ago
    The google people provided exactly that. A WASM polyfill.
    - youngtaff 1y ago
      Not really… it needs a HTML to load the polyfill and transform the XML You can’t have the browser load an XML file and have it transformed automatically as happens now

goku12 1y ago

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.

miohtama 1y ago

You can polyfill this with JavaScript though? It's incorrect to say there are no removals, as we do not have <MARQUEE> anymore.

frosted-flakes 1y ago
Yes we do. https://caniuse.com/mdn-html_elements_marquee https://caniuse.com/mdn-html_elements_marquee The marquee element is deprecated but is supported by all major Web browsers.
ksherlock 1y ago
With xml/xslt, the browser fetches, eg, somefile.xml that looks like: <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="somefile.xsl"?> ... Then the browser fetch somefile.xsl and uses that to transform the xml into html (which is then rendered as per the uzhe). Whether the browser does all that in C or C++ or Rust or Javascript or by sending it to an LLM is an implementation detail. If the browser drops xslt support and just displays it as text (or syntax-hilighted xml), I, as the xml author, can't polyfill that by adding javascript to the xml because it won't be executed. You need to back up a level. You could set up a web page that fetches the xml and fetch the xslt and transforms it into html and then displays it (so a browser in your browser so you can browse while you browse) but I wouldn't call that a polyfill exactly. If you're going to do that, it would be less work and a better user experience to do the transform server side.
- Izkata 1y ago
  Webservers can push CSS through headers, I wonder if that works with javascript too...
- 8NNTt8z3QvLT8tp 1y ago
  https://github.com/mfreed7/xslt_polyfill/pull/5 https://github.com/mfreed7/xslt_polyfill/pull/5 - someone's made a PR that looks like it would allow Mason's polyfill to work directly from the XML file.

_bzuf 1y ago

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.

spankalee 1y ago

Brian's comment here is really important for bystanders to be able to understand the process: https://github.com/whatwg/html/issues/11582#issuecomment-3207518017 https://github.com/whatwg/html/issues/11582#issuecomment-320... 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.

samdoesnothing 1y ago

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

hateful 1y ago

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.

throwmeaway222 1y ago

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

arjie 1y ago

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.

paulvnickerson 1y ago

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.

troupo 1y ago
> This notion that we can't peal away browser spec complexity They are not peeling away browser complexity. They revel in browser complexity. They gleefuly make browser as complex as possible.... as long as their promotions depend on it: https://news.ycombinator.com/item?id=44989576 https://news.ycombinator.com/item?id=44989576
- kstrauser 1y ago
  None of those could be implemented in JavaScript or WASM. XSLT could. Say what you will about the popularity of each of them, but they can't exist without browser implementations. XSLT can be replaced with a polyfill.
  - youngtaff 1y ago
    > XSLT can be replaced with a polyfill Show me how a polyfill allows me to type https://example.com/rss.xml https://example.com/rss.xml in the URL bar and have it transformed to HTML in the browser?
    - kstrauser 1y ago
      I don’t think I’ve ever wanted to read an RSS feed directly, although I subscribe to a lot of them. Is that a popular reading method?
      - troupo 1y ago
        It's a popular presentation format for RSS feeds. And you don't need to somehow attach a Javascript polyfill to an XML feed to make it readable for humans

rand17 1y ago

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.

sunshine-o 1y ago

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.

Telemakhos 1y ago
> I remember you could point to a stylesheet to apply to an XML file. You still can. That's exactly what this article is about: XSLT is that stylesheet. You can publish XML-structured data that machines can ingest, and you can attach XSLT to that data so that humans can view the exact same file in a human-friendly way. The browser constructs, according to the XSL transform rules, a Document Object Model out of the XML, and then it usually applies CSS to that DOM. No duplication of files, no "click here to get to the actual data." I've got some OPML (lists of podcasts) and RSS (podcast) XML files that are also human-readable web pages thanks to this; the exact same web address works for your favorite podcast app and for human viewing. > I really wish we could apply CSS stylesheets to a JSON. I don't think what you want is CSS in the first instance, but in the second: first you'd want a template transformation language like XLST is for XML. You'd want to be able to say not just "show these values in this font" but "for each key matching this pattern, create a DOM element containing that key, then another element containing its value," and then style them with CSS when a whole document has been generated out of the JSON. XML with XSLT almost always also included CSS to handle fonts and whatnot.
- sunshine-o 1y ago
  Oh no you can apply a CSS directly to XML https://www.w3.org/Style/styling-XML.en.html https://www.w3.org/Style/styling-XML.en.html It is simple and works very well for simple documents. Remember, XHTML was just an XML document.

vstollen 1y ago

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]. [1]: https://vstollen.me/atom.xml https://vstollen.me/atom.xml

ptx 1y ago
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.html https://httpd.apache.org/docs/current/en/content-negotiation...
- trekz 1y ago
  It can be done but it's not practical because most RSS readers don't even send an Accept header at all, let alone one with an XML mime type.
  - ptx 1y ago
    But browsers do send the Accept header, so you could default to RSS for requests from other clients (such as RSS readers).

kstrauser 1y ago

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.

chews 1y ago

Booze Allen Hamilton contractors be salivating at the mouth.

thro1 1y ago

> The real reason for the removal is that Google, a profit seeking corporation, considers XSLT to be unprofitable. > Of course, they can't say this out loud, so they instead have @mfreed7 cherry-pick some numbers as justification. ( https://github.com/whatwg/html/issues/11582#issuecomment-3215101504 https://github.com/whatwg/html/issues/11582#issuecomment-321... ) Mason Freed (mfreed7), XSLT, 2025, Jorge Villalobos, 'legacy' Firefox extensions, 2017, ..Mitchell Baker, ..Peter Daszak never will be forgotten for years of programmers lives lost and the pain they causing.