To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute.
To be honest if people are very upset about a feature that might be added or a feature that might be removed the right thing to do is probably to literally just raise it publicly, organize supporters and generally act in protest.
Google may have a lot of control over the web, but note that WEI still didn't ship.
Everyone likes to complain as a user of open source. Nobody likes to do the difficult work.
XSLT is used on the web. That's why people are upset about Google & friends removing it while ignoring user feedback.
Outside of this is a whole universe.
It’s been years since I’ve touched it, but clicking the congressional bill XML link and seeing a perfectly formatted and readable page reminded me of exactly why XSLT has a place. To do the same thing without it, you’d need some other engine to parse the XML, convert it to HTML, and then ensure the proper styles get applied - this could of course be backend or frontend, either way it’s a lot of engineering overhead for a task that, with XSLT, requires just a stylesheet.
No, you can use <?xml-stylesheet ?> directives with CSS to attach a css stylesheet directly to an xml file.
CSS is not as flexible as xslt, but this seems to be very simple formatting which is well within what css is capable of.
It has no process for discussing removal of features or for speaking out against a feature
The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread.
Ultimately the way the community can influence decisions is to not be completely unhinged.
Like someone else said the other way would be to just use XSLT in the first place.
Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize the word "credible" here. You are facing an extremely uphill battle from the visible lack of support for the development; any truly credible offer should have come many years ago. Big projects are well aware of the utility of last-minute, emotionally-driven offers of support in the midst of a burst of publicity, viz, effectively zero.
I don't know that the power is as imbalanced as people think here so much as a very long and drawn out conversation has been had by the web as a whole, on the whole the web has agreed this is not a terribly useful technology by vast bulk of implementation work, and this is the final closing chapter where the browsers are basically implementing the will of the web. The standard for removal isn't "literally 0 usage in the entire world", and whatever the standard is, if XSLT isn't on the "remove" side of it, that would just be a sign it needs to be tuned up because XSLT is a complete non-entity on the web. If you are not feeling like your voice is being respected it's because it's one of literally millions upon millions; what do you expect?
[1]: I know exceptions are reading this post, but you are exceptions. And not terribly common ones.
I have a hard time buying the idea that document templating is some niche use-case compared to pretty much every modern javascript api. More realistically, lots of younger people don't know it's there. People constantly bemoan html's "lack" of client side includes or extensible component systems.
There's probably half-a-dozen other things that could stand serious thought about removal.
There is one major difference though, which is that if you remove webusb, the functionality is just gone, whereas XSLT can be done through Javascript/WebASM just fine.
Document templating is obviously not a niche case. That's why we've got so many hundreds of them. We're not lacking in solutions for document templating, we're drowning in them. If XSLT stands out in its niche, it is as being a particularly bad choice, which is why nobody (to that first approximation we've all heard so much about) uses it.
edit: I see Simon mentioned it - https://simonwillison.net/2025/Aug/19/xslt/ - e.g., https://www.congress.gov/119/bills/hr3617/BILLS-119hr3617ih.... - the site seems to be even less popular than Longhorn Steakhouse in Germany.
My guess is that they'll shuffle people to PDF or move rendering to the server side, which is a common (and, with today's computing power, extremely cheap) way to generate HTML from XML.
Further, PDF and server-side are fine for achieving the same display, but it removes the XML of it all - that is to say, someone might be using the raw XML to lower tools, feeds, etc. if XSLT goes away and congress drops the XML links in favor of PDFs etc, that breaks more than just the pretty formatting
2. One should still be able to retrieve the raw XML document. It's just that it won't be automatically transformed client-side.
It's been a standard part of the Web platform for years. The only question should be, "Is _anyone_ using it?", not whether it's being "used like crazy" or not.
Don't break the Web.
But useful websites are much less likely to be infested by the all consuming Goo admalware.
Seriously, i doubt this.
There was a time where the standard way to build a highly interactive SPA was using SOAP services on the backend combined with iframes on the front end that executed XSLT in the background to update the DOM.
Obviously such an approach is extremely out of date and you won't find it on any websites you use. But, a lot of critical enterprise software was built this way and is kind of stuck like this.
Afaik IE 5 did not support XSLT. It supported a proprietary similar language that was different. I think IE6 was first version to support XSLT.
I feel like when i see enterprise xslt a lot of it is serverside.
It's not for the public to identify these sites. It's for the arrogant Googlers to do a modicum of research
The congress one appears to be the first legit example i have seen.
At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.
Of course. And yet none of the people from Google even seem to be aware of
> The congress one appears to be the first legit example i have seen.
There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss
Again, none of the people from Google even seem to be aware of these use cases, and just power through regardless of any concerns.
I don't see any reason to assume that. I don't think anyone from google is claiming the literal number of sites is 0, just that it is insignificant.
I am very sure the people at google are aware of the rss feed usage.
Don't confuse people disagreeing with you with people not understanding you.
No. No they aren't. As you can see in the discussion: https://github.com/whatwg/html/issues/11523 where the engineer who proposed this literally updates his "analysis" as people point out use cases he missed.
Quote:
--- start quote ---
albertobeta: there is a real-world and modern use case from the podcasting industry, where I work. Collectively, we host over 4.5 million RSS feeds. Like many other podcast hosting companies, we use XSLT to beautify our raw feeds and make them easier to understand when viewed in a browser.
mfreed7, the Googler https://github.com/whatwg/html/issues/11523#issuecomment-315... : Thanks for the additional context on this use case! I'm trying to learn more about it.
--- end quote ---
And then just last week: https://github.com/whatwg/html/issues/11523#issuecomment-318...
--- start quote ---
Thanks for all of the comments, details, and information on this issue. It's clear that XSLT (and talk of removing it) strikes a nerve with some folks. I've learned a lot from the posts here.
--- end quote ---
> Don't confuse people disagreeing with you with people not understanding you.
Oh, they don't even attempt to understand people.
Here's him last week adding a PR to remove XSLT from the spec: https://github.com/whatwg/html/pull/11563
Did he address any of the issues? Does he link to any actual research pointing out how much will be broken, where it's used etc.?
Nope.
But then another Googler pulls up, says "good work, don't forget to remove it everywhere else". End of discussion.
You're angry you didn't get your way, but the googler's decision seems logical, i think most software developers maintaining a large software platform would have made a similar decision given the evidence presented (as evidenced by other web browsers making the same one).
The only difference here between most software is that google operates somewhat in the open. In the corporate world there would be some customer service rep to shield devs from the special interest group's tantrum.
Just like they did the last time when they tried to remove confirm/prompt[1] and were surprised to see that their numbers don't paint the full picture, as literally explicitly explained in their own docs: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
You'd think that the devs of the world's most popular browser would have a little more care than just citing some numbers, ignoring all feedback, and moving forward with whatever they want to do?
Oh. Speaking, of "not just Google".
The question was raised in this meeting: https://github.com/whatwg/html/issues/11146#issuecomment-275... Guess what.
--- start quote ---
dan: even if the data were accurate, not enough zeros for the usage to be low enough.
brian: I'm guessing people will have objections... people do use it and some like it
--- end quote ---
[1] See, e.g. https://gomakethings.com/google-vs.-the-web/
But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript.
I don't want to imply that if they had just added support for XSLT 3.0 then everyone would be using XSLT instead of JavaScript today and the latest SIMD optimizations of Chrome's XPath pipeline would make the HN front-page. The language is just too bad for that.
But I think it's true that there exists a feedback loop: Browsers can and do influence how much a technology is adopted, by making the tech less or more painful to use. Then turning around and saying no one is using the tech, so we'll remove it, is a bit dishonest.
XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player.
There was, at no point, any reason to invest in it any farther.
Moreover, even if you push a button and rewrite history so that even so it was heavily invested in anyhow, I see no reason to believe it would have ever been a major force in that alternate history either. I would personally contend that it has always been a bad idea, and if anything, it has been unduly propped up by the browsers and overinvested in as it is. But perhaps less inflammatorily and more objectively, it has always been a foreign paradigm that most programmers have no experience in, and this was even more true in the "XML all the things!" era which predates the initial Haskell burst that pushed FP forward by a good solid decade, and the prospects of it ever being popular were never all that great.
all i did was to share a link to a resource. if you don't trust that resource you need to do your own testing. what ever i say, whether i tested it or not, doesn't add much more value. you can't trust my words any more than the resource i linked.
you asked half a dozen times in the last few days how a plain xml file can be transformed without xslt. and you claimed that xslt can be used to transform an rss feed.
well, guess what, i just tested this: an rss feed with the standard mimetype application/rss+xml doesn't load either an xsl stylesheet or javascript. to make that work you have to change the mimetype, and if you do that, both the xsl stylesheet or the javascript load. (just not both at the same time)
Why answer if you don’t know the answer
Here’s one that used application/xml and it works https://www.ellyloel.com/feed.rss
People are using xslt in the wild today and JS isn’t really a replacement
application/xml is not the same as application/rss+xml. application/xml also loads javascript just fine. again, i tested that. so far i have not found a single mimetype that can load xslt, but could not load javascript. i am coming to believe that there isn't one. if xslt works, then javascript works too.
whether javascript itself is a suitable replacement for xslt is not the question. your argument was that it is not possible to replace the builtin xslt support with anything written in javascript, because xml files can't load javascript.
since i have now verified that an xml file that can load xslt in the browser can also load javascript, this is proven wrong. all we need now is a good xslt implementation written in javascript or maybe a good binding to a wasm one and then we are ready to remove the builtin xslt support in the browser.
JS referenced by the XML can manipulate the XML but it frequently executes before the XML DOM is ready (even when waiting for onload) and so misses elements
So while possible it’s a pretty horrible experience to translate XML to HTML using JS - the declarative approach is more reliable and easier IMV
The XSLT polyfill doesn’t seem to work when loaded as a script in an XML doc but not quite sure why ATM
application/xml is commonly used for RSS feeds on static hosts because it’s the correct mimetype for say a feeds.xml response
someone else mentioned xjslt here: https://news.ycombinator.com/item?id=44994310 which is an xslt 2.0 implementation. i have been trying to get that to work by loading the script directly into the xml data but so far could not figure out how to do it.
Then browser devs could treat it like an extension (plus some small shims in the core) while the public API wouldn't have to change.
in order to create a menu where the current active page is highlighted and not a link, i need to do this:
<a>
<xsl:choose>
<xsl:when test="@name='home'">
<xsl:attribute name="class">selected</xsl:attribute>
</xsl:when>
<xsl:otherwise>
<xsl:attribute name="href">/</xsl:attribute>
</xsl:otherwise>
</xsl:choose>
home
</a> |
<a>
<xsl:choose>
<xsl:when test="@name='about'">
<xsl:attribute name="class">selected</xsl:attribute>
</xsl:when>
<xsl:otherwise>
<xsl:attribute name="href">/about.xhtml</xsl:attribute>
</xsl:otherwise>
</xsl:choose>
about
</a> |
<xsl:variable name="nav-menu-items">
<item href="foo.xhtml"><strong>Foo</strong> Page</item>
<item href="bar.xhtml"><em>Bar</em> Page</item>
<item href="baz.xhtml">Baz <span>Page</span></item>
</xsl:variable>
<xsl:template match="nav-menu">
<nav>
<ul>
<xsl:apply-templates select="$nav-menu-items/item">
<xsl:with-param name="current" select="@current-page"/>
</xsl:apply-templates>
</ul>
</nav>
</xsl:template>
<xsl:template match="item">
<xsl:param name="current"/>
<li>
<xsl:choose>
<xsl:when test="@href=$current">
<a class="selected"><xsl:apply-templates/></a>
</xsl:when>
<xsl:otherwise>
<a href="{@href}"><xsl:apply-templates/></a>
</xsl:otherwise>
</xsl:choose>
</li>
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:mode on-no-match="shallow-copy"/>
<xsl:variable name="menu-items">
<item href="foo.xhtml"><strong>Foo</strong> Page</item>
<item href="bar.xhtml"><em>Bar</em> Page</item>
<item href="baz.xhtml">Baz <span>Page</span></item>
</xsl:variable>
<xsl:template match="nav-menu">
<nav>
<ul>
<xsl:apply-templates select="$menu-items/item"/>
</ul>
</nav>
</xsl:template>
<xsl:template match="item">
<li>
<xsl:variable name="current-page" select="tokenize(base-uri(/),'/')[last()]"/>
<a href="{if (@href = $current-page) then '' else @href}"
class="{if (@href = $current-page) then 'selected' else ''}">
<xsl:apply-templates/>
</a>
</li>
</xsl:template>
<xsl:template match="nav-menu">
<nav>
<ul>
<li><a href="foo.xhtml">Foo</a></li>
<li><a href="bar.xhtml">Bar</a></li>
<li><a href="baz.xhtml">Baz</a></li>
</ul>
</nav>
</xsl:template>
your last example is what i started out with, including the pass through template. you may remember this message from almost two months ago: https://news.ycombinator.com/item?id=44398626
one comment for the xslt 3 example: href="" doesn't disable the link. it's just turns into a link to self (which it would be anyways if the value was present). the href attribute needs to be gone completely to disable the link.
nodes you output don't have type "node-set" - instead, they're what is called a "result tree fragment". You can store that to a variable, and you can use that variable to insert the fragment into output (or another variable) later on, but you cannot use XPath to query over it.
the xsl documentation https://www.w3.org/TR/xslt-10/#variables says:
Variables introduce an additional data-type into the expression language. This additional data type is called result tree fragment. A variable may be bound to a result tree fragment instead of one of the four basic XPath data-types (string, number, boolean, node-set). A result tree fragment represents a fragment of the result tree. A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. An operation is permitted on a result tree fragment only if that operation would be permitted on a string (the operation on the string may involve first converting the string to a number or boolean). In particular, it is not permitted to use the /, //, and [] operators on result tree fragments.
so using apply-templates on a variable doesn't work. this is actually where i got stuck before. i just was not sure because i could not verify that everything else was correct.
i wonder if it is possible to load the menu from a second document: https://www.w3.org/TR/xslt-10/#document
edit: it is!
<xsl:apply-templates select="document('nav-menu.xml')/menu">
Adding xmlns:exsl="http://exslt.org/common" to your xsl:stylesheet and doing select="exsl:node-set($nav-menu-items)/item" seems to work on both Chrome and Librewolf.
here is the actual stylesheet i am using:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:exsl="http://exslt.org/common" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml">
<xsl:output method="html"/>
<xsl:variable name="nav-menu">
<item href="/">Home</item>
<item href="/about.xhtml">About</item>
</xsl:variable>
<xsl:template match="document">
<html>
<head>
<meta charset="utf-8" />
<title><xsl:value-of select="title" /></title>
<link rel="stylesheet" type="text/css" href="site.css" />
</head>
<body>
<!-- <xsl:apply-templates select="document('nav-menu.xml')/menu"> -->
<xsl:apply-templates select="exsl:node-set($nav-menu)/item">
<xsl:with-param name="current" select="@name"/>
</xsl:apply-templates>
<xsl:apply-templates select="content" />
</body>
</html>
</xsl:template>
<xsl:template match="item">
<xsl:param name="current"/>
<xsl:choose>
<xsl:when test="@href=$current">
<a class="selected"><xsl:apply-templates/></a>
</xsl:when>
<xsl:otherwise>
<a href="{@href}"><xsl:apply-templates/></a>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template match="content">
<xsl:apply-templates select="@*|node()" />
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<?xml-stylesheet type="text/xsl" href="site.xsl"?>
<document name="about">
<title>About Us</title>
<content>
html content here, to be inserted without change
</content>
</document>
<menu>
<item href="/">Home</item>
<item href="/about.xhtml">About</item>
</menu>
<xsl:variable name="nav-menu-items" xmlns="">
<item href="/">Home</item>
<item href="/about.xhtml">About</item>
</xsl:variable>
The test is failing because it's `/about.xhtml` in the template but `about` outside. You'd either need to add a name attribute to item to compare on or make it match the href.
That should make your thing work if I haven't fooled myself again. :)
you are right. i removed it, and it works. typical "copy from stackoverflow" error. these namespaces are a mystery and not intuitive at all. i suppose most people don't notice that because it only applies to xml data within the stylesheet. most people won't have that so they won't notice an issue. the less the better.
for the other error, my mistake, duh! in my original example in https://news.ycombinator.com/item?id=44961352 i am comparing $current/@name to a hardcoded value, so if i want to keep that comparison i have to add that value to the nav-menu data. or use a value that's already in there.
i went with adding a name="about" attribute to the nav-menu because it keeps the documents cleaner: <document name="about"> just looks better, and it also allows me to treat it like an ID that doesn't have to match the URL which allows renaming/moving documents around without having to change the content. (they might go from about.xhtml to about/index.xhtml for example)
i am also probably going to use the document() function instead of exsl:node-set() because having the menu data in a separate file in this case is also easier to manage. it's good to know about that option though. being able to iterate over some local data is a really useful feature. i'll keep that around as an example.
the final piece of the puzzle was:
<xsl:if test="position() != last()"> | </xsl:if>
that sorted, now it all works. thank you again.
btw, it's funny that we are turning hackernews into an xsl support forum. i guess i should write all that up into a post some day.
li + li::before {
content: " | ";
}
You're right on the href; maybe there's not a slick/more "HTML beginner friendly" way to get rid of the <xsl:choose> stuff even in 3.0. I have no experience with 3.0 though since it doesn't work.
I get a little fired up about the XSLT stuff because I remember being introduced to HTML in an intersession school class when I was like... 6? XSLT wasn't around at that time, but I think I maybe learned about it when I was ~12-13, and it made sense to me then. The design of all of the old stuff was all very normal-human approachable and made it very easy to bite a little bit more off at a time to make your own personal web pages. "Use React and JSON APIs" or "use SSR" seems to just be giving up on the idea that non-programmers should be able to participate in the web too. Should we do away with top level HTML/CSS while we're at it and just use DOM APIs?
There were lots of things in the XML ecosystem I didn't understand at the time (what in the world was the point of XSDs and what was a schema and how do you use them to make web pages? I later came to appreciate those as well after having to work as a programmer with APIs that didn't have schema files), but the template expansion thing to make new tags was easy to latch onto.
right, that's a big issue too. when the xsl breaks (in this case when i use <xsl:apply-templates select="$nav-menu-items/item">) i get an empty page and nothing telling me what could be wrong. if i remove the $ the page works, and the apply-templates directive is just left out.
it turns out that because XSLT was largely ignored, it is full of security issues, some of which have been in there for decades.
so the reason XSLT doesn't have a history of exploits is because nobody used it.
What was the point of it though? People transpile from other languages anyway and pull megabytes of npm dependencies.