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.
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.
> 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.
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.
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.
> 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.
This has already been the norm for years. Feed auto discovery is decades old at this point.
> 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.
This is not true. It has always been valid to omit html/head/body tags and the closing tags of several elements. This is a valid HTML 4.01 Strict document, it follows all of the parsing rules of HTML 4.01 correctly, it is not malformed, it parses correctly in every browser, there is no ambiguity, there is no error handling taking place, and there is nothing incorrect at all about it:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title>Valid</title>
<p>This is a valid HTML 4.01 Strict document.
The intention behind this is dropping existing behaviour (XSLT support) and that will break at least some websites. I was saying that when they created HTML 5 they went to great lengths to preserve the HTML parsing behaviour, resulting in the complex parsing and tree construction rules. This is because their goal was to preserve compatibility with existing websites.
I could have chosen a better example like quirks mode. My point was that they could have simplified the parser logic and implementation buren by dropping that. But they didn't.
They even went to great lengths to parse existing XML content (SVG, MathML, and XLink) in HTML documents without supporting namespaces.
So dropping XSLT support here is purely because they don't want to put the effort in implementing their own XSLT engine (in a "safer" language if they need to), or to properly support the maintenance of the open source lbraries they rely on. And dropping XSLT goes against why HTML 5/LS was originally created, which was to support all existing HTML and web content no matter what they looked like.
> My point was that they could have simplified the parser logic and implementation buren by dropping that. But they didn't.
You’re right, and I think this is possibly the biggest mistake the HTML5 standards process ever made. They got that one badly wrong. Strict XML-based parsing was the clearly correct solution informed by many years of Postel’s Law constantly fucking the web up with incompatibilities and security vulnerabilities.
> So dropping XSLT support here is purely because they don't want to put the effort in implementing their own XSLT engine
That’s not the whole answer; they think the benefits don’t justify the effort, and I agree with that.
> And dropping XSLT goes against why HTML 5/LS was originally created, which was to support all existing HTML and web content no matter what they looked like.
That wasn’t why HTML5 was created. That makes no sense; you don’t need a new format to preserve the status quo.
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.
> 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:
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.
Flash was dependent on a proprietary plugin from a single vendor. XSLT styled documents are compatible out of the box in any web browser from multiple competing vendors, even old Internet Explorer.
The iPhone never supported Flash. But thanks to web standards it supports viewing RSS feeds and other weird XML/XSLT artifacts from the past to this day.
What are those low-power devices (can you identify any?) doing with XSLT, then? If they don't have the power to do the transformation, it seems pointless for them to possess the template needed to perform the process.
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).
Commercial enterprises can only support standards if it's commercially viable.
It's commercially beneficial to make the web standard so complex that it's more or less impossible to implement, since it lets you monopolise the browser market. However complexity only protects incumbents if you can persuade enough people to use the overcomplicated bits. If hardly anyone uses it, like xslt, then it's a cost for the incumbent which new entrants might get away without paying. So there's no real upside for Google in supporting it. And you can't expect commercial enterprises to do something without any upside.
I expect commercial enterprises not to be allowed to engage in anti-competitive and consumer-hostile behavior. Like it or not and regardless of their contributions to tech/the web Google is notorious for pulling the rug out from under open industry standards only to replace them with their own proprietary or, as you described, "standards" that are so complex it's more or less impossible to implement so you're "forced" to use/buy their product.
They will be as anti-competitive and as consumer hostile as they can get away with. Adding and removing features from the standard is so ambiguously motivated that I almost can't imagine them being successfully prosecuted for it. In a way it's pretty clever.
Nobody is going to do things you agree with all the time. That doesn't mean everything they do should be condemned by default, without thorough investigation into their motives.
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.
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.
But why would a server send me xml instead of html? From the thread you can see that the servers already serve html so why is there a second way to present that content via xslt?
Because you can do things with XSLT that you can't do with pure HTML
For instance, I can provide an XML file that is a list of widgets, and then I can use to XSLT to give you a table with the values sorted in some way. I can't do that with plain HTML, I'd have to invoke Javascript or something.
Okay, let's say I have a list of widgets that's in an HTML table. How do I sort the list if I don't want to use Javascript or install some programming language on the web server I'm using (let's say I'm using shared hosting and don't have admin access)? I could sort it by hand, but then I'd need to re-do the whole list if I decided to sort it by another column for some reason. And then if I wanted to add entries, I'd have to insert them by hand into their appropriate place and hope that I don't make a mistake
it can be, but because it started as an SGML language (and nowadays who knows what it is) it allows ambiguous structures, plus it doesn't support arbitrary tags, whereas in XML the structure is strict but the tag schema is completely free.
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).
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
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.
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.
The critical part is “cares to expend resources”. Google really wants these communication protocols for whatever reason and is happy to support them, but clearly does not care about Xslt.
> > 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
This is not true. Both Mozilla and Apple rejected WebUSB, WebSerial, and WebBluetooth, and Apple rejected WebMIDI as well. Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand. So yes, browser maintainers definitely do have qualms about shoving those huge attack surfaces in there, and those qualms are a matter of public record you can read at your leisure.
> most of which have as much usage as XSLT
It doesn’t make sense to compare the usage of proposed features to a feature that has been implemented by all browsers for 25 years. Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.
> Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand.
Indeed. And now Google cites lack of resources, complexity, a large attack surface, and small percentage of page views, and barrels forward with removing XSLT. Without a single lengthy discussion.
> Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.
Yes, if a feature is deliberately ignored, let's remove it. That's exactly what happened to SVG for example. Oh wait...
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
> Indeed. And now Google cites lack of resources, complexity, a large attack surface, and small percentage of page views, and barrels forward with removing XSLT. Without a single lengthy discussion.
You’re equivocating here.
You were complaining that browser maintainers had no qualms about adding functionality with large attack surfaces. This was untrue and I pointed out that these things have received a lot of attention from browser maintainers.
You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.
Adding a feature with a large attack surface area is a security risk that needs to be evaluated.
Removing a feature with a large attack surface area is not a security risk – it’s the opposite!
The reason people want to have a lengthy discussion when adding features is to avoid introducing security issues.
The reason you want to have a lengthy discussion when removing XSLT is because you want the XSLT functionality.
These two situations are not the same thing at all but you are presenting them as equivalent.
Furthermore, the security risks of XSLT have already been clearly shown:
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
If you were honestly worried about “the huge attack surface areas” of these features, then you should be glad that they had lengthy discussions beforehand, and you should be worried about XSLT being present in browsers. But instead you are using the discussion of those new features as a way to defend XSLT being present.
> Yo, if a feature is deliberately ignored, let's remove it. That's exactly what hairless to SVG for example. Oh wait...
This makes no sense, SVG is in widespread use.
> On top of that XSLT is used on more web sites than, say, WebSerial
I already explained why it makes no sense to make this comparison.
> You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.
It is.
Large complex spec with a potentially large attack service, but which is still in use (even though small use, but not enough to justify removal according to very same browser vendors who are not Google, and according to Google's own document)?
> then you should be glad that they had lengthy discussions beforehand
I'm not glad, because Google shipped them regardless of any concerns from any of the other browser vendors.
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.
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.
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:
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.
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?
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.
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. ?
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.
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.
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.
> 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
i do that frequently, especially on podcast feeds where i am not actually interested in the rss entries but in the linked audio files. the rss reader doesn't play those well.
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
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 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.
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.
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 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.
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.
The response says that for every provided XML document URL, there is an existing equivalent HTML document URL that accomplishes the same outcome for the end user and that is strongly emphasized by the site's UX. The fact that humans rarely access the XML documents via common browsers is also evident from the available usage metrics.
The question of abstract efficiency via reuse is academic. If the XML documents were the ones that users accessed most of the time, or were the only documents available, that might change the analysis. But that isn't the case.
By that same argument, we could deprecate PDF support, as almost every PDF content on the web has an equivalent and emphasized HTML version.
Or we could deprecate support for .txt and .xml in the browser itself, for the same reasons.
We obviously don't want that. It's valuable to have support for multiple formats, and it's especially valuable to have a single file that can be used by both machines and humans.
Metrics show that users frequently access text and PDF files in their browsers. They almost never access XML files, despite the purported benefit you mention.
Not everything that has a benefit is accepted by customers. Some stuff just doesn't sell.
So here's what you'd do if you wanted to have actual metrics.
1. Analyze which groups of users you've got, and how large they are
2. For each recorded metric, categorize it into the appropriate group
3. Weight each set of metrics by the actual sizes of each user group from step 1
If some users groups have no, or too little data, pay users in these groups to do surveys.
Now you've got actual metrics telling you how many people will be affected.
Going beyond that, measure how long each visit was, and how long each session was. If users don't agree, again, pay them to take surveys or to watch them browse.
Now you can weight the metrics by how many individual sessions will be disrupted, and how much time you've cost users with your decision.
And this is just the very basics of collecting proper metrics, as done by proper polling institutes. You could contract Nielsen (US) or GfK (DE) to do this for you, they've got decades of experience collecting such metrics for all kinds of industries.
But "Number of page loads of opted in users" is a metric that only tells you how many ad views will be disrupted by a change.
Have you considered that the only users who access XML files might be a) at work (where you won't get telemetry) or b) techies, who also disable metrics?
You can't just use the metrics of "what do people who don't know how to disable telemtry use?" to make decisions for everyone.
Where's your proof that it is in use sufficient to justify maintaining the functionality? If you have such data, take it to the decision makers. Nobody's going to make decisions based on hypotheticals in the presence of data.
As more than one VP has said at my company: "In God I trust. Everyone else needs data."
By your logic, nobody should take an action unless the data that supports it is flawless. That's not how the world works and would lead to widespread decision paralysis. Most of the world's progress is based on taking calculated risks based on the information you do have, despite imperfections.
Having a reasonably complete and well-performing set of XML tools available in the browser is really nice.
The counterpoint seems to be "well it has Javascript so we don't need actual features since you can theoretically write anything in JS" but one of the nicest things about it was having that toolkit available to Javascript. You can spin up a DOM for arbitrary XML and apply a bunch of natively-compiled, fast tools to it, coordinating and supplementing that with JS. Then present that to the UI as HTML. It's very nice.
I'm on team "the right move is to upgrade these, not remove them".
If they want to remove things to simplify the spec I've got a list I'd suggest, but it's mostly stuff added in the last decade.
I'm sympathetic to the argument that the feature is an elegant one. But at the same time, maintaining it is not cost-free; every line of code written, imported, or linked poses an ongoing "tax" and/or risk. This is a garden-variety product management decision: is it worth the ongoing maintenance and risk? As a responsible PM, you have to weigh the costs against the benefits, and I think they've presented sufficient evidence users have voted "no" on the benefits.
As I said in another thread, not everything of value or benefit gains meaningful adoption. A rational actor doesn't preserve everything of value for its own sake. At best, we call people who do "museum curators," and at worst, "hoarders."
The people stewarding the Web platform have neglected a lot of nice things, among them this—a major version two major versions ahead of what's in browsers, is eight years old.
That it still has any use on notable sites at all seems like a decent cue to at least try not neglecting it before declaring nobody wants to use it.
... however, it's mostly useful for doing things that owners of walled Web platforms have no interest in, like working with interoperable protocols & formats. They've been killing those through active moves and neglect for 15 years, so why would they do something that makes that easier & nicer?
It seems like a long logical leap that browser authors have no interest in working with interoperable protocols and formats--despite all the work they put into maintaining and improving Javascript (a terrible language since the day it was born), HTML, CSS, downloadable fonts, TLS and other security protocols, SVG and other image formats, security tokens and keys, WebUSB (!), WebRTC, etc.--because they want to drop a feature that practically nobody uses.
> ...because they want to drop a feature that practically nobody uses.
Outside of the Googleplex, I expect that far, far, far fewer people use WebUSB than use XSLT.
Plus, attaching devices that have field-reprogrammable firmware and have always assumed that the only thing that can access them is software running on the local system directly to the worst parts of the Internet seems like a shockingly poor idea, from a security perspective.
I'm no champion of WebUSB, and I have no idea what its usage stats are. I'm only saying that the idea that browser vendors are on some sort of mission to stifle open standards and interoperability is ludicrous on its face.
There are some that would say that moving a standard that covers a large number of complicated things from a versioned standard to a "living standard" makes interoperability impossible for all but the most well-financed organizations. I agree with this assertion.
I'll also point out that (for quite a long while now) only two companies produce the major browser engines: Google and Apple. Mozilla Firefox doesn't count as an independent entity because without the funding from Google, it would have shut down long, long ago.
So, anyway. If Google wants to remove a complicated, security-compromising feature that very, very, very few people use, they should REALLY start with WebUSB.
> XSLT accomplishes what json-ld and semantic html never managed.
What are you talking about, it’s accomplished practically nothing‽
XSLT is a way to write code that takes one XML file and turns it into a different XML file. Its primary use case is to make RSS feeds look nicer in browsers. That’s it. It hasn’t solved the Semantic Web.
Google isn't even "sponsoring" the idea. Mason's just the one who opened these issues and PRs after the meetings. Lots of platform maintainers from various vendors are interested in this. They all have rotting XSLT impelmentations with security holes.
> 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.
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.
It's also worth noting that mfreed7 of Chromium (the person who initiated the proposal) is not the one who came up with the 357 number; that was zcorpan of Mozilla ( https://github.com/whatwg/html/issues/11523#issuecomment-320... ), so mfreed7 is talking about the list they got from zcorpan.
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.
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
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.
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...
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
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.
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.
> 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.
at:// urls were unfortunately mis-designed as explained in https://github.com/bluesky-social/atproto-website/issues/417
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.
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.
> 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.
This has already been the norm for years. Feed auto discovery is decades old at this point.
> 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.
This is not true. It has always been valid to omit html/head/body tags and the closing tags of several elements. This is a valid HTML 4.01 Strict document, it follows all of the parsing rules of HTML 4.01 correctly, it is not malformed, it parses correctly in every browser, there is no ambiguity, there is no error handling taking place, and there is nothing incorrect at all about it:
The intention behind this is dropping existing behaviour (XSLT support) and that will break at least some websites. I was saying that when they created HTML 5 they went to great lengths to preserve the HTML parsing behaviour, resulting in the complex parsing and tree construction rules. This is because their goal was to preserve compatibility with existing websites.
I could have chosen a better example like quirks mode. My point was that they could have simplified the parser logic and implementation buren by dropping that. But they didn't.
They even went to great lengths to parse existing XML content (SVG, MathML, and XLink) in HTML documents without supporting namespaces.
So dropping XSLT support here is purely because they don't want to put the effort in implementing their own XSLT engine (in a "safer" language if they need to), or to properly support the maintenance of the open source lbraries they rely on. And dropping XSLT goes against why HTML 5/LS was originally created, which was to support all existing HTML and web content no matter what they looked like.
> My point was that they could have simplified the parser logic and implementation buren by dropping that. But they didn't.
You’re right, and I think this is possibly the biggest mistake the HTML5 standards process ever made. They got that one badly wrong. Strict XML-based parsing was the clearly correct solution informed by many years of Postel’s Law constantly fucking the web up with incompatibilities and security vulnerabilities.
> So dropping XSLT support here is purely because they don't want to put the effort in implementing their own XSLT engine
That’s not the whole answer; they think the benefits don’t justify the effort, and I agree with that.
> And dropping XSLT goes against why HTML 5/LS was originally created, which was to support all existing HTML and web content no matter what they looked like.
That wasn’t why HTML5 was created. That makes no sense; you don’t need a new format to preserve the status quo.
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.
> but why priviligize XML?
Because it was privileged at the start and now it’s been a working feature you could rely on for a generation.
> there's WASM and sites can have any kinds of codecs they want.
Can’t js your way into the browser opening an xml document and automatically applying the stylesheet as far as I know.
> 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)
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.
Flash was never a web standard. XLST is.
What's the practical different to users and site maintainers?
Flash was dependent on a proprietary plugin from a single vendor. XSLT styled documents are compatible out of the box in any web browser from multiple competing vendors, even old Internet Explorer.
The iPhone never supported Flash. But thanks to web standards it supports viewing RSS feeds and other weird XML/XSLT artifacts from the past to this day.
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.
XSLT is often used on low-power IOT devices which don't have the resources to render server-side
What are those low-power devices (can you identify any?) doing with XSLT, then? If they don't have the power to do the transformation, it seems pointless for them to possess the template needed to perform the process.
that's why they use XSLT. the whole point is that rendering happens in on the client.
you can find discussion in the several other recent XSLT threads
RSS/Atom feeds can use them. How does it make sense to maintain two versions of the same data on the server?
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). For the curious, the XLST can be found here: 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/XSLTProcess...
There are no easy fixes for government sites.
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).
Commercial enterprises can only support standards if it's commercially viable.
It's commercially beneficial to make the web standard so complex that it's more or less impossible to implement, since it lets you monopolise the browser market. However complexity only protects incumbents if you can persuade enough people to use the overcomplicated bits. If hardly anyone uses it, like xslt, then it's a cost for the incumbent which new entrants might get away without paying. So there's no real upside for Google in supporting it. And you can't expect commercial enterprises to do something without any upside.
I expect commercial enterprises not to be allowed to engage in anti-competitive and consumer-hostile behavior. Like it or not and regardless of their contributions to tech/the web Google is notorious for pulling the rug out from under open industry standards only to replace them with their own proprietary or, as you described, "standards" that are so complex it's more or less impossible to implement so you're "forced" to use/buy their product.
They will be as anti-competitive and as consumer hostile as they can get away with. Adding and removing features from the standard is so ambiguously motivated that I almost can't imagine them being successfully prosecuted for it. In a way it's pretty clever.
Nobody is going to do things you agree with all the time. That doesn't mean everything they do should be condemned by default, without thorough investigation into their motives.
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.
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.
XSLT uhhh notably doesn't actually have better alternatives available.
html?
You're thinking of XML, not XSLT. XSLT is a language for transforming XML into other structures.
But why would a server send me xml instead of html? From the thread you can see that the servers already serve html so why is there a second way to present that content via xslt?
Because you can do things with XSLT that you can't do with pure HTML
For instance, I can provide an XML file that is a list of widgets, and then I can use to XSLT to give you a table with the values sorted in some way. I can't do that with plain HTML, I'd have to invoke Javascript or something.
When you program a list of widgets you can program it against anything though. Whether its xml or html.
Okay, let's say I have a list of widgets that's in an HTML table. How do I sort the list if I don't want to use Javascript or install some programming language on the web server I'm using (let's say I'm using shared hosting and don't have admin access)? I could sort it by hand, but then I'd need to re-do the whole list if I decided to sort it by another column for some reason. And then if I wanted to add entries, I'd have to insert them by hand into their appropriate place and hope that I don't make a mistake
keeping data orthogonal to presentation
How is html not data?
it can be, but because it started as an SGML language (and nowadays who knows what it is) it allows ambiguous structures, plus it doesn't support arbitrary tags, whereas in XML the structure is strict but the tag schema is completely free.
How do you create a HTML RSS feed?
By rendering it on the server and serving it to the client.
And is that RSS feed is part pf a blog that’s static content?
> 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
nit: document.applets is not the same as the <applet> tag.
https://developer.mozilla.org/en-US/docs/Web/API/Document/ap...For instance: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
Also see https://github.com/mdn/content/pull/26850 which removed MDN docs for the element a couple years back, citing removals from major browsers.<font> and <frameset> are still implemented in browsers, though, even if they are fully deprecated and marked by WHATWG as obsolete and non-conforming: https://html.spec.whatwg.org/multipage/obsolete.html#non-con...
Thank you for the correction!
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?
There’s an explicit deside to unship XSLT on the browsers’ part, from what I understand. That’s what motivated the spec proposal in the first place.
Easy: The WHAATWG hasn't decided to remove XLST. They are starting the process of deciding now.
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).
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
It really should just be compiled to WASM and used with some sort of DOM bridge.
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.
The google people provided exactly that. A WASM polyfill.
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
> 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...
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.
The critical part is “cares to expend resources”. Google really wants these communication protocols for whatever reason and is happy to support them, but clearly does not care about Xslt.
> > 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
This is not true. Both Mozilla and Apple rejected WebUSB, WebSerial, and WebBluetooth, and Apple rejected WebMIDI as well. Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand. So yes, browser maintainers definitely do have qualms about shoving those huge attack surfaces in there, and those qualms are a matter of public record you can read at your leisure.
> most of which have as much usage as XSLT
It doesn’t make sense to compare the usage of proposed features to a feature that has been implemented by all browsers for 25 years. Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.
> Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand.
Indeed. And now Google cites lack of resources, complexity, a large attack surface, and small percentage of page views, and barrels forward with removing XSLT. Without a single lengthy discussion.
> Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.
Yes, if a feature is deliberately ignored, let's remove it. That's exactly what happened to SVG for example. Oh wait...
On top of that XSLT is used on more web sites than, say, WebSerial which managed to climb to a whooping 0.000596% this year https://chromestatus.com/metrics/feature/timeline/popularity...
To quote Chrome's own document:
--- start quote ---
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
--- end quote ---
> Indeed. And now Google cites lack of resources, complexity, a large attack surface, and small percentage of page views, and barrels forward with removing XSLT. Without a single lengthy discussion.
You’re equivocating here.
You were complaining that browser maintainers had no qualms about adding functionality with large attack surfaces. This was untrue and I pointed out that these things have received a lot of attention from browser maintainers.
You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.
Adding a feature with a large attack surface area is a security risk that needs to be evaluated.
Removing a feature with a large attack surface area is not a security risk – it’s the opposite!
The reason people want to have a lengthy discussion when adding features is to avoid introducing security issues.
The reason you want to have a lengthy discussion when removing XSLT is because you want the XSLT functionality.
These two situations are not the same thing at all but you are presenting them as equivalent.
Furthermore, the security risks of XSLT have already been clearly shown:
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
— https://www.offensivecon.org/speakers/2025/ivan-fratric.html
— https://www.youtube.com/watch?v=U1kc7fcF5Ao
If you were honestly worried about “the huge attack surface areas” of these features, then you should be glad that they had lengthy discussions beforehand, and you should be worried about XSLT being present in browsers. But instead you are using the discussion of those new features as a way to defend XSLT being present.
> Yo, if a feature is deliberately ignored, let's remove it. That's exactly what hairless to SVG for example. Oh wait...
This makes no sense, SVG is in widespread use.
> On top of that XSLT is used on more web sites than, say, WebSerial
I already explained why it makes no sense to make this comparison.
> You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.
It is.
Large complex spec with a potentially large attack service, but which is still in use (even though small use, but not enough to justify removal according to very same browser vendors who are not Google, and according to Google's own document)?
> then you should be glad that they had lengthy discussions beforehand
I'm not glad, because Google shipped them regardless of any concerns from any of the other browser vendors.
Oh, they also shipped large currently unused specs without even providing a spec for other browsers to look at (looking at WebTransport). Imagine if that had any CVE entries https://nvd.nist.gov/vuln/detail/CVE-2024-7255 https://nvd.nist.gov/vuln/detail/CVE-2025-1931
> This makes no sense, SVG is in widespread use.
SVG was also sort of languishing in v1 with no interest to update it and make it more usable. But then SVG 2 happened.
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)
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.
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.
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:
Some existing standards/specs/proposals I cribbed this from:- https://html.spec.whatwg.org/multipage/scripting.html#the-te...
- (defunct) https://html.spec.whatwg.org/multipage/form-elements.html#th...
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.
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
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...
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.
But browsers do send the Accept header, so you could default to RSS for requests from other clients (such as RSS readers).
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.
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. ?
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.
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.
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.
> 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
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.
> XSLT can be replaced with a polyfill
Show me how a polyfill allows me to type https://example.com/rss.xml in the URL bar and have it transformed to HTML in the browser?
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?
i do that frequently, especially on podcast feeds where i am not actually interested in the rss entries but in the linked audio files. the rss reader doesn't play those well.
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
how do you do that with anything else?
firefox doesn't load the file at all, but loads it into an external tool which (gasp!) is chrome. chrome displays the raw xml.
Brian's comment here is really important for bystanders to be able to understand the process: 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.
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.
i’m strongly in favor of simplifying the standard
> 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-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.
You can polyfill this with JavaScript though?
It's incorrect to say there are no removals, as we do not have <MARQUEE> anymore.
With xml/xslt, the browser fetches, eg, somefile.xml that looks like:
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.
Webservers can push CSS through headers, I wonder if that works with javascript too...
Yes we do.
https://caniuse.com/mdn-html_elements_marquee
The marquee element is deprecated but is supported by all major Web browsers.
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 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.
Oh no you can apply a CSS directly to XML 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.
Booze Allen Hamilton contractors be salivating at the mouth.
This is a fair response to the point:
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.
How is it a fair response? Isn't it desirable to have a format that can be used by machines and humans at the same time?
XSLT accomplishes what json-ld and semantic html never managed.
The response says that for every provided XML document URL, there is an existing equivalent HTML document URL that accomplishes the same outcome for the end user and that is strongly emphasized by the site's UX. The fact that humans rarely access the XML documents via common browsers is also evident from the available usage metrics.
The question of abstract efficiency via reuse is academic. If the XML documents were the ones that users accessed most of the time, or were the only documents available, that might change the analysis. But that isn't the case.
By that same argument, we could deprecate PDF support, as almost every PDF content on the web has an equivalent and emphasized HTML version.
Or we could deprecate support for .txt and .xml in the browser itself, for the same reasons.
We obviously don't want that. It's valuable to have support for multiple formats, and it's especially valuable to have a single file that can be used by both machines and humans.
Metrics show that users frequently access text and PDF files in their browsers. They almost never access XML files, despite the purported benefit you mention.
Not everything that has a benefit is accepted by customers. Some stuff just doesn't sell.
So here's what you'd do if you wanted to have actual metrics.
1. Analyze which groups of users you've got, and how large they are
2. For each recorded metric, categorize it into the appropriate group
3. Weight each set of metrics by the actual sizes of each user group from step 1
If some users groups have no, or too little data, pay users in these groups to do surveys.
Now you've got actual metrics telling you how many people will be affected.
Going beyond that, measure how long each visit was, and how long each session was. If users don't agree, again, pay them to take surveys or to watch them browse.
Now you can weight the metrics by how many individual sessions will be disrupted, and how much time you've cost users with your decision.
And this is just the very basics of collecting proper metrics, as done by proper polling institutes. You could contract Nielsen (US) or GfK (DE) to do this for you, they've got decades of experience collecting such metrics for all kinds of industries.
But "Number of page loads of opted in users" is a metric that only tells you how many ad views will be disrupted by a change.
In this instance, why not compare against page loads of documents that have the same substantive content but in a different format?
Also, I'm not sure where ads came into this discussion; none of the documents at issue here have ads in them.
Re: ads, because that's the only use case where unique views is actually relevant.
We're dealing in raw page load counts here, not unique views.
Have you considered that the only users who access XML files might be a) at work (where you won't get telemetry) or b) techies, who also disable metrics?
You can't just use the metrics of "what do people who don't know how to disable telemtry use?" to make decisions for everyone.
Where's your proof that it is in use sufficient to justify maintaining the functionality? If you have such data, take it to the decision makers. Nobody's going to make decisions based on hypotheticals in the presence of data.
As more than one VP has said at my company: "In God I trust. Everyone else needs data."
I'm arguing that such decisions shouldn't be taken based on flawed metrics, and here you demand I produce my own flawed metrics to "prove" my point.
This isn't really leading anywhere.
By your logic, nobody should take an action unless the data that supports it is flawless. That's not how the world works and would lead to widespread decision paralysis. Most of the world's progress is based on taking calculated risks based on the information you do have, despite imperfections.
Having a reasonably complete and well-performing set of XML tools available in the browser is really nice.
The counterpoint seems to be "well it has Javascript so we don't need actual features since you can theoretically write anything in JS" but one of the nicest things about it was having that toolkit available to Javascript. You can spin up a DOM for arbitrary XML and apply a bunch of natively-compiled, fast tools to it, coordinating and supplementing that with JS. Then present that to the UI as HTML. It's very nice.
I'm on team "the right move is to upgrade these, not remove them".
If they want to remove things to simplify the spec I've got a list I'd suggest, but it's mostly stuff added in the last decade.
I'm sympathetic to the argument that the feature is an elegant one. But at the same time, maintaining it is not cost-free; every line of code written, imported, or linked poses an ongoing "tax" and/or risk. This is a garden-variety product management decision: is it worth the ongoing maintenance and risk? As a responsible PM, you have to weigh the costs against the benefits, and I think they've presented sufficient evidence users have voted "no" on the benefits.
As I said in another thread, not everything of value or benefit gains meaningful adoption. A rational actor doesn't preserve everything of value for its own sake. At best, we call people who do "museum curators," and at worst, "hoarders."
The people stewarding the Web platform have neglected a lot of nice things, among them this—a major version two major versions ahead of what's in browsers, is eight years old.
That it still has any use on notable sites at all seems like a decent cue to at least try not neglecting it before declaring nobody wants to use it.
... however, it's mostly useful for doing things that owners of walled Web platforms have no interest in, like working with interoperable protocols & formats. They've been killing those through active moves and neglect for 15 years, so why would they do something that makes that easier & nicer?
It seems like a long logical leap that browser authors have no interest in working with interoperable protocols and formats--despite all the work they put into maintaining and improving Javascript (a terrible language since the day it was born), HTML, CSS, downloadable fonts, TLS and other security protocols, SVG and other image formats, security tokens and keys, WebUSB (!), WebRTC, etc.--because they want to drop a feature that practically nobody uses.
> ...because they want to drop a feature that practically nobody uses.
Outside of the Googleplex, I expect that far, far, far fewer people use WebUSB than use XSLT.
Plus, attaching devices that have field-reprogrammable firmware and have always assumed that the only thing that can access them is software running on the local system directly to the worst parts of the Internet seems like a shockingly poor idea, from a security perspective.
I'm no champion of WebUSB, and I have no idea what its usage stats are. I'm only saying that the idea that browser vendors are on some sort of mission to stifle open standards and interoperability is ludicrous on its face.
There are some that would say that moving a standard that covers a large number of complicated things from a versioned standard to a "living standard" makes interoperability impossible for all but the most well-financed organizations. I agree with this assertion.
I'll also point out that (for quite a long while now) only two companies produce the major browser engines: Google and Apple. Mozilla Firefox doesn't count as an independent entity because without the funding from Google, it would have shut down long, long ago.
So, anyway. If Google wants to remove a complicated, security-compromising feature that very, very, very few people use, they should REALLY start with WebUSB.
https://www.congress.gov/bill/117th-congress/house-bill/3617 isn't really a comparable link to https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih....
But I think that was maybe just a mistake? Maybe he meant https://www.congress.gov/bill/117th-congress/house-bill/3617...
> XSLT accomplishes what json-ld and semantic html never managed.
What are you talking about, it’s accomplished practically nothing‽
XSLT is a way to write code that takes one XML file and turns it into a different XML file. Its primary use case is to make RSS feeds look nicer in browsers. That’s it. It hasn’t solved the Semantic Web.
Google isn't even "sponsoring" the idea. Mason's just the one who opened these issues and PRs after the meetings. Lots of platform maintainers from various vendors are interested in this. They all have rotting XSLT impelmentations with security holes.
I've got to admire Mason's chill in actually giving concrete replies to what are mostly ad-hominem attacks around this issue.
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.
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.
The very first issue was locked and limited to collaborators.
It's also worth noting that mfreed7 of Chromium (the person who initiated the proposal) is not the one who came up with the 357 number; that was zcorpan of Mozilla ( https://github.com/whatwg/html/issues/11523#issuecomment-320... ), so mfreed7 is talking about the list they got from zcorpan.
You’re saying a nice guy, who is not obligated to engage and chooses to, is not allowed to mock an intellectually dishonest issue?
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.
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
[flagged]
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.
It's great for admin areas.
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...
> righteous keyboard warriors
Worst comic ever!
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
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.
How did this become a case of us vs them? Government websites are meant for our benefit.