The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks...
For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
> I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
I think if Gecko crashed less that'd be great.
I think if Gecko starts selling me a VPN service, and the parent org gets busy doing a bunch of real-estate investments, I wonder if you're making a web browser anymore.
> the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…)
I'm sorry I disagree.
I am hearing them say they can't make the web happen, because it's hard and they're not very good at programming, they put so many bugs in their code they just can't fix it, and it's really interfering with their efforts to add another privacy-impacting feature that they can use to sell more ads.
I think if every one of them got hit by a bus tomorrow absolutely nothing would change on the web except maybe we'd keep XSLT for another six months.
I want to appreciate anything you've done for Gecko, but it's hard if you don't realise it's people like me made the web happen too: I've been building web applications since 1994, and my applications have run on billions of devices at this point, and paid for my house, and some twenty years ago I used XSLT.
Do you really think I should bail them out by rewriting my fully working code so they don't have to fix their smelly broken code? You really think I have no standing to be a little bit annoyed by that attitude?
Also, "Smaug, Anne, Emilo" did not "make the web happen." They have influenced how the web has developed, in particular favouring functionality and uses that are dependent on Javascript, and neglecting to ensure parity of opportunity for other approaches to flourish.
It sucks, people just doing their job should be treated with respect.
That said I can also feel like the technocratic decision making process make it so some people aren't given any voice nor choice. Its whatever the US tech giants want that decides for the rest of us.
The problem with browsers is that they rely on other standards. If a browser needs to maintain backward compatibility and requires an evolving standard that ALSO requires backward compatibility, this acts like a multiplier on implementation complexity. This also means it becomes increasingly difficult to spin up a new browser engine, and the fewer of those there are, the easier it is for the big ones to just add what they want and have it become a standard, reinforcing the issue.
Would you say the same about CSS if browsers only supported version 1.0 while it was being used in many other contexts and version 4.0 was being worked on?
Isn't it a shame that we can only have one program installed on our computers.
Imagine (if you can!) being able to have two programs, one (program A) that supports JS and all that shite, and another (program B) that supports XSLT and all that shite. If you're still with me imagine that program A could just call program B when it detects stuff that it doesn't support and vice versa.
I know, I know, a measly 16 core CPU with 32Gi of memory is not going to be capable of such feats, but one can dream...
I'd consider JS and WASM quite a bit more risky from a security standpoint, which is why everyone should refuse loading and executing those by default.
Securing an XSLT 3.0 implementation would be much easier.
How is the answer to any question "Should we remove X from the web platform?" where X wasn't introduced in the last week an has actual users not a resounding "No, WTF is wrong with you.".
This could be debatable if browsers had any UI at all to display XML. It's incomprehensible that if you open the open web solution for subscribing to web content (RSS) you're greeted with a wall of unformatted text. Right now, XSLT is the poor fix to that browser's basic inability.
I am reminded of when Google attempted to kill MathML a few years ago because it was complexity and no one was using it (… because Chromium didn’t support it—all others did). There was widespread rebellion, and it actually led to Igalia implementing it and Google accepting and shipping it.
It wouldn’t surprise me to see a resurgence of interest in XSLT after this, if only for formatting Atom/RSS feeds.
(BTW, prefer Atom unless you’re operating in podcasting, it’s far more sane in ways that occasionally actually matter, and everything supports it except in podcasting which Apple ruined. If you want a featureful stylesheet to look at for reference, mine is the best I know of: https://chrismorgan.info/atom.xsl, https://temp.chrismorgan.info/2022-05-10-rss.xsl.)
I'd like to genuinely ask: what's the benefit of providing a visually appealing feed? I thought feeds were meant for programs. Do you/people directly browse individual feeds? Nice feed look BTW!
> I don't think there's a strong "Open Web" argument to be made here. XML data files being able to be reformatted into HTML is somewhat of an accident of history; we don't have similar functionality for any other data type, despite, for example, JSON files being vastly more common on the web than XML.
Ironically, we would have support for transforming JSON if XSLT in the browser had been kept up-to-date.
Interestingly, "XML data files being able to be reformatted into HTML" was a deliberate choice to support and encourage the separation of content and presentation. CSS was introduced for the same reason but to address a slightly different (but complimentary) aspect of the same ambition and it's flourished. Imagine how widely CSS would be being used if browser support was still stuck at CSS 1.0.
U.S. legislation is delivered on the web as XSLT-styled XML and depends on web browsers continuing to provide native support for client-side XSLT. Examples:
My blogroll's better-known than my actual site, and it's feed-reader compatible OPML that I've just made fun with additional attributes and XSLT. A server-side transform to vend duplicate OPML and HTML would be a bummer. I'm not an Important Web Platform user or anything, but I wish more people would share their feed-reader exports – and I've thought about trying to share tooling to extend/display them like this. It'll be sad if that ends up impossible.
I tried to comment on this just now but I was blocked as the thread has been limited to collaborators, their word not mine, but wow.
So I guess I'll put it here assuming someone reads.
Given the various comments people have about the dependencies on XSLT that various standards, applications and workflows have. I believe that the default display of XML documents in Chrome, Firefox, and I suppose Edge is handled by an XSLT.
It used to be that MSXML shipped with an XSLT (and even earlier a wd-xsl document) as a resource that was used to style any XML document for display if the XML document did not have an associated stylesheet when you opened it in IE or other views that used IE for rendering.
I believe this same thing is done by the browsers mentioned, or at least it used to be
which is why when you open an XML document without styling information in those documents it is represented as a tree view with expandable collapsible nodes.
I suppose they will just implement a default rendering for XML using some other code rather than running an XSLT upon it, but this applies as well as all these edge cases of handling RSS feeds etc.
Safari does not have a stylesheet rendering for unstyled XML which is why it just shows the text nodes of the document and nothing else.
31 comments
[ 6.0 ms ] story [ 54.0 ms ] threadXSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments):
https://news.ycombinator.com/item?id=44393817
The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
I see it hasn't changed.
I think if Gecko crashed less that'd be great.
I think if Gecko starts selling me a VPN service, and the parent org gets busy doing a bunch of real-estate investments, I wonder if you're making a web browser anymore.
> the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…)
I'm sorry I disagree.
I am hearing them say they can't make the web happen, because it's hard and they're not very good at programming, they put so many bugs in their code they just can't fix it, and it's really interfering with their efforts to add another privacy-impacting feature that they can use to sell more ads.
I think if every one of them got hit by a bus tomorrow absolutely nothing would change on the web except maybe we'd keep XSLT for another six months.
I want to appreciate anything you've done for Gecko, but it's hard if you don't realise it's people like me made the web happen too: I've been building web applications since 1994, and my applications have run on billions of devices at this point, and paid for my house, and some twenty years ago I used XSLT.
Do you really think I should bail them out by rewriting my fully working code so they don't have to fix their smelly broken code? You really think I have no standing to be a little bit annoyed by that attitude?
The vast majority of comments on https://github.com/whatwg/html/issues/11523 are polite and respectful.
Also, "Smaug, Anne, Emilo" did not "make the web happen." They have influenced how the web has developed, in particular favouring functionality and uses that are dependent on Javascript, and neglecting to ensure parity of opportunity for other approaches to flourish.
A lot of the hate is actually justified (with the exception of hixxie)
That said I can also feel like the technocratic decision making process make it so some people aren't given any voice nor choice. Its whatever the US tech giants want that decides for the rest of us.
Imagine (if you can!) being able to have two programs, one (program A) that supports JS and all that shite, and another (program B) that supports XSLT and all that shite. If you're still with me imagine that program A could just call program B when it detects stuff that it doesn't support and vice versa.
I know, I know, a measly 16 core CPU with 32Gi of memory is not going to be capable of such feats, but one can dream...
Securing an XSLT 3.0 implementation would be much easier.
[1] https://thedailywtf.com/articles/Sketchy-Skecherscom
It wouldn’t surprise me to see a resurgence of interest in XSLT after this, if only for formatting Atom/RSS feeds.
(BTW, prefer Atom unless you’re operating in podcasting, it’s far more sane in ways that occasionally actually matter, and everything supports it except in podcasting which Apple ruined. If you want a featureful stylesheet to look at for reference, mine is the best I know of: https://chrismorgan.info/atom.xsl, https://temp.chrismorgan.info/2022-05-10-rss.xsl.)
> I don't think there's a strong "Open Web" argument to be made here. XML data files being able to be reformatted into HTML is somewhat of an accident of history; we don't have similar functionality for any other data type, despite, for example, JSON files being vastly more common on the web than XML.
Ironically, we would have support for transforming JSON if XSLT in the browser had been kept up-to-date.
Interestingly, "XML data files being able to be reformatted into HTML" was a deliberate choice to support and encourage the separation of content and presentation. CSS was introduced for the same reason but to address a slightly different (but complimentary) aspect of the same ambition and it's flourished. Imagine how widely CSS would be being used if browser support was still stuck at CSS 1.0.
https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL...
Shortly after that, Google Chrome want to remove XSLT support.
Coincidence?
My blogroll's better-known than my actual site, and it's feed-reader compatible OPML that I've just made fun with additional attributes and XSLT. A server-side transform to vend duplicate OPML and HTML would be a bummer. I'm not an Important Web Platform user or anything, but I wish more people would share their feed-reader exports – and I've thought about trying to share tooling to extend/display them like this. It'll be sad if that ends up impossible.
So I guess I'll put it here assuming someone reads.
Given the various comments people have about the dependencies on XSLT that various standards, applications and workflows have. I believe that the default display of XML documents in Chrome, Firefox, and I suppose Edge is handled by an XSLT.
It used to be that MSXML shipped with an XSLT (and even earlier a wd-xsl document) as a resource that was used to style any XML document for display if the XML document did not have an associated stylesheet when you opened it in IE or other views that used IE for rendering.
I believe this same thing is done by the browsers mentioned, or at least it used to be
https://stackoverflow.com/questions/9463402/default-xml-styl...
which is why when you open an XML document without styling information in those documents it is represented as a tree view with expandable collapsible nodes.
I suppose they will just implement a default rendering for XML using some other code rather than running an XSLT upon it, but this applies as well as all these edge cases of handling RSS feeds etc.
Safari does not have a stylesheet rendering for unstyled XML which is why it just shows the text nodes of the document and nothing else.