One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use.
I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link.
But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish).
XSLT is currently the only way to make feeds into something that can still be viewed.
I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO).
I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/
Isn't this kind of an argument for dropping it? Yeah it would be great if it was in use but even the people who are clicking and providing RSS feeds don't seem to care that much.
Gotta love the reference to the <link> header element. There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.
> There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.
This is actually a feature of Orion[0], and among the reasons why I believe it to be one of the most (power) user-oriented browsers in active development.
It's such a basic thing that there's really no good reason to remove the feature outright (as mainstream browsers have), especially when the cited reason is to "reduce clutter" which has been added back tenfold with garbage like chatbots and shopping assistants.
Man, reaching way back in history here, but this reminds me of why I stopped contributing to Mozilla decades ago. My contribution was the link toolbar, that was supposed to give a UI representation of the canonical link elements like next and prev and whatnot. At the last minute before a major release some jerkhole of a product manager at AOL cut my feature from the release. It's incredible the way such pretty bureaucrats have shaped web browsers over the years.
iIRC, all of the proposed workarounds involved updating the sites using XSLT, which may not always be particularly easy, or even something publishers will realize they need to do.
For RSS/Atom feeds presented as links in a site (for convenience to users), developers can always offer a simple preview for the feed output using: https://feedreader.xyz/
> Cancelling XSLT is going in the wrong direction (IMHO).
XSLT isn't going anywhere: hardwiring into the browser an implementation that's known to be insecure and is basically unmaintained is what's going away. The people doing the wailing/rending/gnashing about the removal of libxslt needed to step up to fix and maintain it.
It seems like something an extension ought to be capable of, and if not, fix the extension API so it can. In firefox I think it would be a full-blown plugin, which is a lower-level thing than an extension, but I don't know whether Chromium even has a concept of such a thing.
> XSLT isn't going anywhere: hardwiring into the browser an implementation that's known to be insecure and is basically unmaintained is what's going away.
Not having it available from the browser really reduces the ability to use it in many cases, and lots of the nonbrowser XSLT ecosystem relies on the same insecure, unmaintained implementation. There is at least one major alternative (Saxon), and if browser support was switching backing implementation rather than just ending support, “XSLT isn’t going anywhere” would be a more natural conclusion, but that’s not, for whatever reason, the case.
I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one.
"XSLT is currently the only way to make feeds into something that can still be viewed."
You could use content negotiation just fine. I just hit my personal rss.xml file, and the browser sent this as the Accept header:
You can easily ship out an HTML rendering of an RSS file based on this. You can have your server render an XSLT if you must. You can have your server send out some XSLT implemented in JS that will come along at some point.
To a first approximation, nobody cares enough to use content negotiation any more than anyone cares about providing XML stylesheets. The tech isn't the problem, the not caring is... and the not caring isn't actually that big a problem either. It's been that way for a long time and we aren't actually all that bothered about it. It's just a "wouldn't it be nice" that comes up on those rare occasions like this when it's the topic of conversation and doesn't cross anyone's mind otherwise.
> I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one.
Maybe it's more for people who have no idea what RSS is and click on the intriguing icon. If they weren't greeted with a load of what seems like nonsense for nerds there could have been broader adoption of RSS.
> I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one.
So that excludes you from the "someone who hasn't seen/used a RSS reader" demographic mentioned in the comment you are replying to.
It's encouraging to see browsers actually deprecate APIs, when I think a lot of problems with the Web and Web security in particular is people start using new technologies too fast but don't stop using old ones fast enough.
That said, it's also pretty sad. I remember back in the 2000s writing purely XML websites with stylesheets for display, and XML+XSLT is more powerful, more rigorous, and arguably more performant now in the average case than JSON + React + vast amounts of random collated libraries which has become the Web "standard".
But I guess LLMs aren't great at generating XSLT, so it's unlikely to gain back that market in the near future. It was a good standard (though not without flaws), I hope the people who designed it are still proud of the influence it did have.
> I remember back in the 2000s writing purely XML websites with stylesheets for display
Yup, "been there, done that" - at the time I think we were creating reports in SQL Server 2000, hooked up behind IIS.
It feels this is being deprecated and removed because it's gone out of fashion, rather than because it's actually measurably worse than whatever's-in-fashion-today... (eg React/Node/<whatever>)
> I remember back in the 2000s writing purely XML websites with stylesheets for display
Awesome! I made a blog using XML+XSLT, back in high school. It was worth it just to see the flabbergasted look on my friends faces when I told them to view the source code of the page, and it was just XML with no visible HTML or CSS[0].
Agreed on API deprecation, the surface is so broad at this point that it's nearly impossible to build a browser from scratch. I've been doing webdev since 2009 and I'm still finding new APIs that I've never heard of before.
To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all).
I think being able to do client-side templating without JS is an important feature and I hope that since browser vendors are removing XSLT they will add some kind of client-side templating to replace it.
> I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all)
Recent XSLT parser exploits were literally the reason this whole push to remove it was started, so this change will specifically be helping people in your shoes.
The percentage of visitors who block JS is extremely small. Many of those visits are actually bots and scrapers that don’t interpret JS. Of the real users who block JS, most of them will enable JS for any website they actually want to visit if it’s necessary.
What I’m trying to say is that making any product decision for the extremely small (but vocal) minority of users who block JS is not a good product choice. I’m sorry it doesn’t work for your use case, but having the entire browser ecosystem cater to JS-blocking legitimate users wouldn’t make any sense.
I block JS, too. And so does about 1-2% of all Web users. JavaScript should NOT be REQUIRED to view a website. It makes web browsing more insecure and less private, makes page load times slower, and wastes energy.
The point of the poster you're responding to is that sites are built JS-first for 98-99% of users, and it takes extra work to make them compatible with "JavaScript should NOT be REQUIRED to view a website", and no one is going to bother doing that work for 1-2% of users.
To put that in context, about 6 percent of US homes have no internet access at all. The “I turn off JS” crowd is at least 3x smaller than the crowd with no access at all.
The JS ship sailed years ago. You can turn it off but a bunch of things simply will not work and no amount of insisting that it would not be required will change that.
I’m not saying change is not possible. I’m saying the change you propose is misguided. I do not believe the entire world should abandon JS to accommodate your unusual preferences nor should everyone be obliged to build two versions of their site, one for the masses and one for those with JS turned off.
Yes, JS is overused. But JS also brings significant real value to the web. JS is what has allowed websites to replace desktop apps in many cases.
Did I say abandon? No. I said it should not be required. JavaScript should be supplementary to a page, but not necessary to view it. This was its original intent.
> JS is what has allowed websites to replace desktop apps in many cases.
Horribly at that, with poorer accessibility features, worse latency, abused visual style that doesn't match the host operating system, unusable during times of net outages, etc, etc.
> JavaScript should be supplementary to a page, but not necessary to view it.
I’m curious. Do Google Maps, YouTube, etc even work with JS off?
> This was its original intent.
Original intent is borderline irrelevant. What matters is how it is actually used and what value it brings.
> Horribly at that
I disagree. You say you turn JS off for security but JS has made billions of people more secure by creating a sandbox for these random apps to run in. I can load up a random web app and have high confidence that it can’t muck with my computer. I can’t do the same with random desktop apps.
> I’m curious. Do Google Maps, YouTube, etc even work with JS off?
I use KDE Marble (OpenStreetMap) and Invidious. They work fine.
> Original intent is borderline irrelevant. What matters is how it is actually used and what value it brings.
And that's why webshit is webshit.
> I can’t do the same with random desktop apps.
I can, and besides the point, why should anyone run random desktop apps? (Rhetorical question, they shouldn't.) I don't run code that I don't trust. And I don't trust code that I can't run for any purpose, read, study, edit, or share. I enforce this by running a totally-free (libre) operating system, booted with a totally-free BIOS, and installing and using totally-free software.
Without saying whether I think that's a good or bad thing, as a practical matter, I 100% agree. Approximately no major websites spend any effort whatsoever supporting non-JS browsers today. They probably put that in the class of text only browsers, or people who override all CSS: "sure, visitors can do that, but if they've altered their browser's behavior then what happens afterward is on them."
And frankly, from an economic POV, I can't blame them. Imagine a company who write a React-based website. (And again, I'm not weighing in on the goodness or badness of that.) Depending on how they implemented it, supporting a non-JS version may literally require a second, parallel version of the site. And for what, to cater to 1-2% of users? "Hey boss, can we triple our budget to serve two versions of the site, kept in lockstep and feature identical so that visitors don't scream at us, to pick up an extra 1% or 2% of users, who by definition are very finicky?" Yeah, that's not happening.
I've launched dozens of websites over the years, all of them using SSR (or HTML templates as we called them back in the day). I've personally never written a JavaScript-native website. I'm not saying the above because I built a career on writing JS or something. And despite that, I completely understand why devs might refuse to support non-JS browsers. It's a lot of extra work, it means they can't use the "modern" (React launched in 2013) tools they're use to, and all without any compelling financial benefit.
Of note here is that the segment we're talking about is actually an intersection of two very small cohorts; the first, as you note, are people who don't own a television errr disable Javascript, and the second is sites that actually rely on XSLT, of which there are vanishingly few.
The "severe security issue" in libxml2 they mention is actually a non-issue and the code in question isn't even used by Chrome. I'm all for switching to memory-safe languages but badmouthing OSS projects is poor style.
Google is too cheap to fund or maintain the library they've built their browser with after its hobbyist maintainers got burnt out, for more than a decade so they're ripping out the feature.
Their whole browser is made up of unsafe languages and their attempt to sort of make c++ safer has yet to produce a usable proof of concept compiler. This is a fat middle finger in the face of all the people's free work they grabbed to collect billions for their investors.
Sounded like the maintainers of libxml2 have stepped-back, so there needs to be a supported replacement, because it is widely used. (Or if you are worried the reputation of "OSS", you can volunteer!)
The issue in question is just one of the several long-unfixed vulnerabilities we know about, from a library that doesn't have that many hands or eyes on it to begin with.
Maintaining web standards without breaking backwards compatibility is literally what they signed up for when they decided to make a browser. If they didn't want to do that job, they shouldn't have made one.
Nobody is badmouthing open source. It's the core truth, open source libraries can become unmaintained for a variety of reasons, including the code base becoming a burden to maintain by anyone new.
And you know what? That's completely fine. Open source doesn't mean something lives forever
Where's the best collection or entry point to what you've written about Chrome's use of Gnome's XML libraries, the maintenance burden, and the dearth of offers by browser makers foot the bill?
Makes me kind of sad. I started my carrier back in days when XHTML and co were lauded as the next thing. I worked with SOAP and WDSLs. I loved that one can express nearly everything in XML. And namespaces… Then came json and apart from being easier to read for humans I wondered why we switch from this one great exchange format to this half baked one. But maybe I’m just nostalgic. But every time I deal with json parsers for type serialization and the question how to express HashMaps and sets, how to provide type information etc etc I think back to XML and the way that everything was available on board. Looked ugly as hell though :)
That's upsetting. Being able to do templating without using JavaScript was a really cool party trick.
I've used it in an unfinished website where all data was stored in a single XML file and all markup was stored in a single XSLT file. A CGI one-liner then made path info available to XSLT, and routing (multiple pages) was achieved by doing string tests inside of the XSLT template.
In my opinion this is not “we agree lets remove it”. This is “we agree to explore the idea”.
Google and Freed using this as a go ahead because the Mozilla guy pasted a pollyfill. However it is very clearly NOT an endorsement to remove it, even though bad actors are stating so.
> Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support1. If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance.
Freed et al also explicitly chose to ignore user feedback for their own decision and not even try to improve XSLT security issues at the cost of performance.
Yeah all these billion dollar corporations that can’t be bothered see it as the only path forward not because of technological or practical issues, but because none of them can be asked to give a shit and plan it into their budgets.
They’re MBAs who only know how to destroy and consolidate as trained.
I’m a modern developer and I see it as valuable. Why side with the browser teams and ignoring user feedback?
If “modern developers” actually spent time with it, they’d find it valuable. Modern developers are idiots if their constant cry is “just write it in JS”.
No idea what’s inaccurate about this. A billion dollar company that has no problem pivoting otherwise, can’t fund open technology “because budgets” is simply a lie.
If you are using XSLT to make your RSS or atom feeds readable in a browser should somebody click the link you may find this post by Jake Archibald useful: https://jakearchibald.com/2025/making-xml-human-readable-wit... - it provides a JavaScript-based alternative that I believe should work even after Chrome remove this feature.
Ah, so this is removing libxslt. For a minute I thought XSLT processing was provided by libxml2, and I remembered seeing that the Ladybird browser project just added a dependency on libxml2 in their latest progress update https://ladybird.org/newsletter/2025-10-31/.
I'm curious to see what happens going forward with these aging and under-resourced—yet critical—libraries.
I think that's sad. XSLT is in my point a view a very misunderstood technology. It gets hated on a lot. I wonder if this hate is by people who actually used and understood it, though. In any case, more often than not this is by people who in the same sentence endorse JavaScript (which, by any objective way of measuring is just a language far more poorly designed).
I'm not much of a programmer, but XSLT being declarative means that I can knock out a decent-looking template without having to do a whole lot of programming work.
Au contraire: the more you understand and use XSLT, the more you hate it. People who don't understand it and haven't used it don't have enough information and perspective to truly hate it properly. I and many other people don't hate XSLT out of misunderstanding at all: just the opposite.
XSLT is like programming with both hands tied behind your back, or pedaling a bicycle with only one leg. For any non-trivial task, you quickly hit a wall of complexity or impossibility, then the only way XSLT is useful is if you use Microsoft's non-standard XSLT extensions that let you call out to JavaScript, then you realize it's so easy and more powerful to simply do what you want directly in JavaScript there's absolutely no need for XSLT.
I understand XSLT just fine, but it is not the only templating language I understand, so I have something to compare it with. I hate XSLT and vastly prefer JavaScript because I've known and used both of them and other worse and better alternatives (like Zope Page Templates / TAL / METAL / TALES, TurboGears Kid and Genshi, OpenLaszlo, etc).
>My (completely imaginary) impression of the XSLT committee is that there must have been representatives of several different programming languages (Lisp, Prolog, C++, RPG, Brainfuck, etc) sitting around the conference table facing off with each other, and each managed to get a caricature of their language's cliche cool programming technique hammered into XSLT, but without the other context and support it needed to actually be useful. So nobody was happy!
>Then Microsoft came out with MSXML, with an XSL processor that let you include <script> tags in your XSLT documents to do all kinds of magic stuff by dynamically accessing the DOM and performing arbitrary computation (in VBScript, JavaScript, C#, or any IScriptingEngine compatible language). Once you hit a wall with XSLT you could drop down to JavaScript and actually get some work done. But after you got used to manipulating the DOM in JavaScript with XPath, you being to wonder what you ever needed XSLT for in the first place, and why you don't just write a nice flexible XML transformation library in JavaScript, and forget about XSLT.
You should really try some of the modern alternatives. Don't let Angular and React's templating systems poison you, give Svelte a try!
Even just plain JavaScript is much better and more powerful and easier to use than XSLT. There are many JavaScript libraries to help you with templates. Is there even any such thing as an XSLT library?
Is there some reason you would prefer to use XSLT than JavaScript? You can much more easily get a job yourself or hire developers who know JavaScript. Can you say the same thing for XSLT, and would anyone in their right mind hire somebody who knows XSLT but refuses to use JavaScript?
XSLT is so clumsy and hard to modularize, only good for messy spaghetti monoliths, no good for components and libraries and modules and frameworks, or any form of abstraction.
And then there's debugging. Does a good XSLT debugger even exist? Can it hold a candle to all the off-the-shelf built-in JavaScript debuggers that every browser includes? How do you even debug and trace through your XSLT?
I know it makes me an old and I am biased because one of the systems in my career I am most proud of I designed around XSLT transformations, but this is some real bullshit and a clear case why a private company should not be the de facto arbiter of web standards. Have a legacy system that depends on XSLT in the browser? Sucks to be you, one of our PMs decided the cost-benefit just wasn't there so we scrapped it. Take comfort in the fact our team's velocity bumped up for a few weeks.
And yes I am sour about the fact as an American I have to hope the EU does something about this because I know full-well it's not happening here in The Land of the Free.
I don't use XSLT and don't object to this, but seeing "security" cited made me realize how reflexively distrustful I've become of them using that justification for a given decision. Is this one actually about security? Who knows!
Didn't this come pretty directly after someone found some security vulns? I think the logic was, this is a huge chunk of code that is really complex which almost nobody uses outside of toy examples (and rss feeds). Sure, we fixed the issue just reported, but who knows what else is lurking here, it doesn't seem worth it.
As a general rule, simplifying and removing code is one of the best things you can do for security. Sure you have to balance that with doing useful things. The most secure computer is an unplugged computer but it wouldn't be a very useful one; security is about tradeoffs. There is a reason though that security is almost always cited - to some degree or another, deleting code is always good for security.
> As a general rule, simplifying and removing code is one of the best things you can do for security.
Sure, but that’s not what they’re doing in the big picture. XSLT is a tiny drop in the bucket compared to all the surface area of the niche, non-standard APIs tacked onto Chromium. It’s classic EEE.
My understanding is that contrary to popular opinion it is firefox not chrome that originally pushed for the removal, so i dont know how relavent that is. It seems like all browser vendors are in agreement on xslt.
that said, xslt is a bit of a weird api in how it interacts with everything. Not all apis are equally risky and i suspect xslt is pretty high up there on the risk vs reward ratio.
There are security issues in the C implementation they currently use. They could remove this without breaking anything by incorporating the JS XSLT polyfill into the browser. But they won't because money.
> Finding and exploiting 20-year-old bugs in web browsers
> 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.
> When that solution isn't wanted, the polyfill offers another path.
A solution is only a solution if it solves the problem.
This sort of thing, basically a "reverse X/Y problem", is an intellectually dishonest maneuver, where a thing is dubbed a "solution" after just, like, redefining the problem to not include the parts that make it a problem.
The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke.
> As mentioned previously, the RSS/Atom XML feed can be augmented with one line, <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>, which will maintain the existing behavior of XSLT-based transformation to HTML.
Oh, yeah? It's that easy? So the Chrome team is going to ship a solution where when it encounters un-un-fucked content that depends on XSLT, Chrome will transparently fix it up as if someone had injected this polyfill import into the page, right? Or is this another instance where well-paid engineers on the Chrome team who elected to accept the responsibility of maintaining the stability of the Web have decided that they like the getting-paid part but don't like the maintaining-the-stability-of-the-Web part and are talking out of both sides of their mouths?
> So the Chrome team is going to ship a solution where when it encounters un-un-fucked content that depends on XSLT, Chrome will transparently fix it up as if someone had injected this polyfill import into the page, right?
As with most things on the web, the answer is "They will if it breaks a website that a critical mass of users care about."
Your response is like seeing the cops going to the wrong house to kick in your neighbors door, breaking their ornaments in their entry way, and then saying to yourself, "Good. I hate yellow, and would never have any of that tacky shit in my house."
As your first sentence of your comment indicates, the fact that it's supported and there for people to use doesn't (and hasn't) result in you being forced to use it in your projects.
Yes but software, and especially browser, complexity has balooned enormously over the years. And while XSLT probably plays a tiny part in that, it's likely embedded in every Electron app that could do in 1MB what it takes 500 MB to do, makes it incrementally harder to build and maintain a competing browser, etc., etc. It's not zero cost.
I do tend to support backwards compatibility over constant updates and breakage, and needless hoops to jump through as e.g. Apple often puts its developers through. But having grown up and worked in the overexuberant XML-for-everything, semantic-web 1000-page specification, OOP AbstractFactoryTemplateManagerFactory era, I'm glad to put some of that behind us.
Remove crappy JS APIs and other web-tech first before deprecating XSLT - which is a true-blue public standard. For folks who don't enable JS and XML data, XSLT is a life-saver.
Unquestionably the right move. From the various posts on HN about this, it's clear that (A) not many people use it (B) it increases security vulnerability surface area (C) the few people who do claim to use have nothing to back up the claim
The major downside to removing this seems to be that a lot of people LIKE it. But eh, you're welcome to fork Chromium or Firefox.
Chrome and other browsers could virtually completely mitigate the security issues by shipping the polyfil they're suggesting all sites depending on XSLT deploy in the browser. By doing so, their XSLT implementation would become no less secure than their javascript implementation (and fat chance they'll remove that). The fact that they've rejected doing so is a pretty clear indication that security is just an excuse, IMO.
"The reality is that for all of the work that we've put into HTML, and CSS, and the DOM, it has fundamentally utterly failed to deliver on its promise.
It's even worse than that, actually, because all of the things we've built aren't just not doing what we want, they're holding developers back. People build their applications on frameworks that _abstract out_ all the APIs we build for browsers, and _even with those frameworks_ developers are hamstrung by weird limitations of the web."
Nice find — interesting to see browsers moving to drop XSLT support.
I used XSLT once for a tiny site and it felt like magic—templating without JavaScript was freeing.
But maybe it’s just niche now, and browser vendors see more cost than payoff.
Curious: have any of you used XSLT in production lately?
I lead a team that manage trade settlements for hedge funds; data is exported from our systems as XML and then transformed via XSLT into whatever format the prime brokers require.
All the transformed are maintained by non-developers, business analysts mainly. Because the language is so simple we don't need to give them much training, just get IntelliJ installed on their machine, show them a few samples and let them work away.
> Didn't this effort start with Mozilla and not Google?
Maybe round one of it like ten years ago did? From what I understand, it's a Google employee who opened the "Hey, I want to get rid of this and have no plans to provide a zero-effort-for-users replacement." Github Issue a few months back.
> It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it.
I don't see any evidence of that claim from the materials I have available to me. [0] is the Github Issue I mentioned. [1] is the WHATNOT meeting notes linked to from that GH Issue... though I have no idea who smaug is.
Blame Apple and Mozilla, too, then. They all agreed to remove it.
They all agreed because XSLT is extremely unpopular and worse than JS in every way. Performance/bloat? Worse. Security? MUCH worse. Language design? Unimaginably worse.
EDIT: I wrote thousands of lines of XSLT circa 2005. I'm grateful that I'll never do that again.
This is only repeated by people who have never used it.
XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).
I used to use XSLT a lot, though it was a while ago.
You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code.
Do you have a particular example where you think Javascript might be more verbose than XSLT?
I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty.
Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!
It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...
I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every popular CI system for "YAML is not a programming language".
That doesn't mean that XML isn't useful. Just not as a programming language.
But, that's what XSL is! XSL is a Turing-complete programming language in XML for processing XML documents. Being in XML is a big part of what makes XSL so awful to write.
XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages.
Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.
> It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...
npm isn't even a build tool, it's a package manager and at that it's actually gotten quite decent - the fact that the JS ecosystem at large doesn't give a fuck about respecting semantic versioning or keeps reinventing the wheel or that NodeJS / JavaScript itself lacks a decent standard library aren't faults of npm ;)
Maven and Gradle in contrast are one-stop-shops, both build orchestrators and dependency managers. As for ant, oh hell yes I'm aware of that. The most horrid build system I encountered in my decade worth of tenure as "the guy who can figure out pretty much any nuclear submarine project (aka, only surfaces every few years after everyone working on it departed)" involved Gradle, which then orchestrated Maven and Ant, oh and the project was built on a Jenkins that was half DSL, half clicked together in the web UI, and the runner that executed the builds was a manually set up, "organically grown" server. That one was a holy damn mess to understand, unwind, clean up and migrate to Gitlab.
> look at pretty much every popular CI system for "YAML is not a programming language".
Oh yes... I only had the misfortune of having to code for Github Actions once in my life time, it's utter fucking madness compared to GitLab.
Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense.
Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)
> 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.
> XSLT is extremely unpopular and worse than JS in every way
This isn't a quorum of folks torpedoing a proposed standard. This is a decades-old stable spec and an established part of the Web platform, and welching on their end of the deal will break things, contra "Don't break the Web".
They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons.
Only Google is pushing forward and twisting that message.
> They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons.
Mozilla:
> Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support.
> WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support, though if there's a known list of origins that participate in a reverse origin trial we could perhaps participate sooner.
Good, XSLT was crap. I wrote an RSS feed XSLT template. Worst dev experience ever. No one is/was using XSLT. Removing unused code is a win for browsers. Every anti bloat HNer should be cheering
I'm always puzzled by statements like this. I'm not much of a programmer and I wrote a basic XSLT document to transform rss.xml into HTML in a couple of hours. I didn't find it very hard at all (anecdotes are not data, etc)
The first few times you use it, XSLT is insane. But once something clicks, you figure out the kinds of things it’s good for.
I am not really a functional programming guy. But XSLT is a really cool application of functional programming for data munging, and I wouldn’t have believed it if I hadn’t used it enough for it to click.
XSLT's matching rules allow a 'push' style of transform that's really neat. But you can actually do that with any programming language such as Javascript.
Right. I didn't use it much on the client side so I am not feeling this particular loss so keenly.
But server side, many years ago I built an entire CMS with pretty arbitrary markup regions that a designer could declare (divs/TDs/spans with custom attributes basically) in XSLT (Sablotron!) with the Perl binding and a customised build of HTML Tidy, wrapped up in an Apache RewriteRule.
So designers could do their thing with dreamweaver or golive, pretty arbitrarily mark up an area that they wanted to be customisable, and my CMS would show edit markers in those locations that popped up a database-backed textarea in a popup.
What started off really simple ended up using Sablotron's URL schemes to allow a main HTML file to be a master template for sub-page templates, merge in some dynamic functionality etc.
And the thing would either work or it wouldn't (if the HTML couldn't be tidied, which was easy enough to catch).
The Perl around the outside changed very rarely; the XSLT stylesheet was fast and evolved quite a lot.
Actually a transformation system can reduce bloat, as people don't have to write their own crappy JavaScript versions of it.
Being XML the syntax is a bit convoluted, but behind that is a good functional (in sense of functional programming language, not functioning) system which can be used for templating etc.
The XML made it a bit hard to get started and anti-XML-spirit reduced motivation to get into it, but once you know it, it beats most bloaty JavaScript stuff in that realm by a lot.
Although it's sad to see an interesting feature go, they're not wrong about security. It's more important to have a small attack surface if this was maintained by one guy in Nebraska and he doesn't maintain it any more.
No, XSLT isn't required for the open web. Everything you can do with XSLT, you can also do without XSLT. It's interesting technology, but not essential.
Yes, this breaks compatibility with all the 5 websites that use it.
One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use.
I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link.
But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish).
XSLT is currently the only way to make feeds into something that can still be viewed.
I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO).
I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/
You can see it in action on an RSS feed here (served as real XML, not HTML: do view/source): https://www.fileformat.info/news/rss.xml
> not that many feeds are actually doing this
Isn't this kind of an argument for dropping it? Yeah it would be great if it was in use but even the people who are clicking and providing RSS feeds don't seem to care that much.
We do the same with our feeds at Standard Ebooks: https://standardebooks.org/feeds/rss/new-releases
The page is XML but styled with XSLT.
FWIW the original post explicitly mentioned this use case and offered two ways to workaround.
Gotta love the reference to the <link> header element. There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.
> There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.
This is actually a feature of Orion[0], and among the reasons why I believe it to be one of the most (power) user-oriented browsers in active development.
It's such a basic thing that there's really no good reason to remove the feature outright (as mainstream browsers have), especially when the cited reason is to "reduce clutter" which has been added back tenfold with garbage like chatbots and shopping assistants.
[0]: https://kagi.com/orion/
Man, reaching way back in history here, but this reminds me of why I stopped contributing to Mozilla decades ago. My contribution was the link toolbar, that was supposed to give a UI representation of the canonical link elements like next and prev and whatnot. At the last minute before a major release some jerkhole of a product manager at AOL cut my feature from the release. It's incredible the way such pretty bureaucrats have shaped web browsers over the years.
iIRC, all of the proposed workarounds involved updating the sites using XSLT, which may not always be particularly easy, or even something publishers will realize they need to do.
Here's a 3rd option :)
For RSS/Atom feeds presented as links in a site (for convenience to users), developers can always offer a simple preview for the feed output using: https://feedreader.xyz/
Just URL-encode the feed like so: https://feedreader.xyz/?url=https%3A%2F%2Fwww.theverge.com%2...
...and you get a nice preview that's human readable.
> Cancelling XSLT is going in the wrong direction (IMHO).
XSLT isn't going anywhere: hardwiring into the browser an implementation that's known to be insecure and is basically unmaintained is what's going away. The people doing the wailing/rending/gnashing about the removal of libxslt needed to step up to fix and maintain it.
It seems like something an extension ought to be capable of, and if not, fix the extension API so it can. In firefox I think it would be a full-blown plugin, which is a lower-level thing than an extension, but I don't know whether Chromium even has a concept of such a thing.
> XSLT isn't going anywhere: hardwiring into the browser an implementation that's known to be insecure and is basically unmaintained is what's going away.
Not having it available from the browser really reduces the ability to use it in many cases, and lots of the nonbrowser XSLT ecosystem relies on the same insecure, unmaintained implementation. There is at least one major alternative (Saxon), and if browser support was switching backing implementation rather than just ending support, “XSLT isn’t going anywhere” would be a more natural conclusion, but that’s not, for whatever reason, the case.
Your argument here includes that browsers should retain native XSLT implementations because non-browsers have bad XSLT implementations?
What do you find questionable about this being included as part of the broader argument?
I just don't understand it. I don't understand it well enough to call out what's questionable about it.
Or perhaps the multi-billion-dollar corporations could stop piggy-backing on volunteers and invest in maintaining the Web platform?
Another use case I discovered and implemented many years ago was styling a sitemap.xml for improved UX / aesthetics.
I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one.
"XSLT is currently the only way to make feeds into something that can still be viewed."
You could use content negotiation just fine. I just hit my personal rss.xml file, and the browser sent this as the Accept header:
except it has no newline, which I added for HN.You can easily ship out an HTML rendering of an RSS file based on this. You can have your server render an XSLT if you must. You can have your server send out some XSLT implemented in JS that will come along at some point.
To a first approximation, nobody cares enough to use content negotiation any more than anyone cares about providing XML stylesheets. The tech isn't the problem, the not caring is... and the not caring isn't actually that big a problem either. It's been that way for a long time and we aren't actually all that bothered about it. It's just a "wouldn't it be nice" that comes up on those rare occasions like this when it's the topic of conversation and doesn't cross anyone's mind otherwise.
You've been in the RSS world since the beginning and never seen a stylized feed?
I've not been in the RSS world very much. I don't use news readers. And even I have seen a stylized RSS in the wild.
Our individual experiences are of course anecdotal, I'm just surprised at how different they are given your background.
> nor have I seen one.
Once upon a time, nice in-browser rendering of RSS/Atom feeds complete with search and sorting was a headliner feature of Safari.
https://www.askdavetaylor.com/how_do_i_subscribe_to_rss_feed...
I think it used to be more popular in early days. At one point i think firefox was styling rss feeds by default so people stopped using xslt as much.
You can still style them with css if you want. I dont really see the point. RSS is for machines to read not humans.
> I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one.
Maybe it's more for people who have no idea what RSS is and click on the intriguing icon. If they weren't greeted with a load of what seems like nonsense for nerds there could have been broader adoption of RSS.
The phrase you are looking for to describe this discourse is “concern trolling.”
> I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one.
So that excludes you from the "someone who hasn't seen/used a RSS reader" demographic mentioned in the comment you are replying to.
It's encouraging to see browsers actually deprecate APIs, when I think a lot of problems with the Web and Web security in particular is people start using new technologies too fast but don't stop using old ones fast enough.
That said, it's also pretty sad. I remember back in the 2000s writing purely XML websites with stylesheets for display, and XML+XSLT is more powerful, more rigorous, and arguably more performant now in the average case than JSON + React + vast amounts of random collated libraries which has become the Web "standard".
But I guess LLMs aren't great at generating XSLT, so it's unlikely to gain back that market in the near future. It was a good standard (though not without flaws), I hope the people who designed it are still proud of the influence it did have.
> I remember back in the 2000s writing purely XML websites with stylesheets for display
Yup, "been there, done that" - at the time I think we were creating reports in SQL Server 2000, hooked up behind IIS.
It feels this is being deprecated and removed because it's gone out of fashion, rather than because it's actually measurably worse than whatever's-in-fashion-today... (eg React/Node/<whatever>)
Yeah it was great. You could sort/filter/summarize in different ways all without a server round-trip. At the time it seemed magical to users.
> I remember back in the 2000s writing purely XML websites with stylesheets for display
Awesome! I made a blog using XML+XSLT, back in high school. It was worth it just to see the flabbergasted look on my friends faces when I told them to view the source code of the page, and it was just XML with no visible HTML or CSS[0].
[0] https://www.w3schools.com/xml/simplexsl.xml - example XML+XSLT page from w3schools
Agreed on API deprecation, the surface is so broad at this point that it's nearly impossible to build a browser from scratch. I've been doing webdev since 2009 and I'm still finding new APIs that I've never heard of before.
This has been chewed on ad nauseum on HN already, to the point I won't even try to make a list of the articles but just link a search result: https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
KPIs of the hottest languages on the web show that XSLT has become hotter that Java and C++ in the last days. XML is back, dudes!
To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all).
I think being able to do client-side templating without JS is an important feature and I hope that since browser vendors are removing XSLT they will add some kind of client-side templating to replace it.
> I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all)
Recent XSLT parser exploits were literally the reason this whole push to remove it was started, so this change will specifically be helping people in your shoes.
> I block JS
The percentage of visitors who block JS is extremely small. Many of those visits are actually bots and scrapers that don’t interpret JS. Of the real users who block JS, most of them will enable JS for any website they actually want to visit if it’s necessary.
What I’m trying to say is that making any product decision for the extremely small (but vocal) minority of users who block JS is not a good product choice. I’m sorry it doesn’t work for your use case, but having the entire browser ecosystem cater to JS-blocking legitimate users wouldn’t make any sense.
I block JS, too. And so does about 1-2% of all Web users. JavaScript should NOT be REQUIRED to view a website. It makes web browsing more insecure and less private, makes page load times slower, and wastes energy.
The point of the poster you're responding to is that sites are built JS-first for 98-99% of users, and it takes extra work to make them compatible with "JavaScript should NOT be REQUIRED to view a website", and no one is going to bother doing that work for 1-2% of users.
> And so does about 1-2% of all Web users.
To put that in context, about 6 percent of US homes have no internet access at all. The “I turn off JS” crowd is at least 3x smaller than the crowd with no access at all.
The JS ship sailed years ago. You can turn it off but a bunch of things simply will not work and no amount of insisting that it would not be required will change that.
I'm hearing you say, "don't waste your breath because change is not possible." And there you have your self-fulfilling prophecy.
To quote someone who lived before me: don't accept the things you cannot change. Change the things you cannot accept.
And the no-JS ship has not sailed. Government websites require accessibility, and at least in the UK, do not rely on JS.
Then you misheard me.
I’m not saying change is not possible. I’m saying the change you propose is misguided. I do not believe the entire world should abandon JS to accommodate your unusual preferences nor should everyone be obliged to build two versions of their site, one for the masses and one for those with JS turned off.
Yes, JS is overused. But JS also brings significant real value to the web. JS is what has allowed websites to replace desktop apps in many cases.
Did I say abandon? No. I said it should not be required. JavaScript should be supplementary to a page, but not necessary to view it. This was its original intent.
> JS is what has allowed websites to replace desktop apps in many cases.
Horribly at that, with poorer accessibility features, worse latency, abused visual style that doesn't match the host operating system, unusable during times of net outages, etc, etc.
> JavaScript should be supplementary to a page, but not necessary to view it.
I’m curious. Do Google Maps, YouTube, etc even work with JS off?
> This was its original intent.
Original intent is borderline irrelevant. What matters is how it is actually used and what value it brings.
> Horribly at that
I disagree. You say you turn JS off for security but JS has made billions of people more secure by creating a sandbox for these random apps to run in. I can load up a random web app and have high confidence that it can’t muck with my computer. I can’t do the same with random desktop apps.
> I’m curious. Do Google Maps, YouTube, etc even work with JS off?
I use KDE Marble (OpenStreetMap) and Invidious. They work fine.
> Original intent is borderline irrelevant. What matters is how it is actually used and what value it brings.
And that's why webshit is webshit.
> I can’t do the same with random desktop apps.
I can, and besides the point, why should anyone run random desktop apps? (Rhetorical question, they shouldn't.) I don't run code that I don't trust. And I don't trust code that I can't run for any purpose, read, study, edit, or share. I enforce this by running a totally-free (libre) operating system, booted with a totally-free BIOS, and installing and using totally-free software.
Without saying whether I think that's a good or bad thing, as a practical matter, I 100% agree. Approximately no major websites spend any effort whatsoever supporting non-JS browsers today. They probably put that in the class of text only browsers, or people who override all CSS: "sure, visitors can do that, but if they've altered their browser's behavior then what happens afterward is on them."
And frankly, from an economic POV, I can't blame them. Imagine a company who write a React-based website. (And again, I'm not weighing in on the goodness or badness of that.) Depending on how they implemented it, supporting a non-JS version may literally require a second, parallel version of the site. And for what, to cater to 1-2% of users? "Hey boss, can we triple our budget to serve two versions of the site, kept in lockstep and feature identical so that visitors don't scream at us, to pick up an extra 1% or 2% of users, who by definition are very finicky?" Yeah, that's not happening.
I've launched dozens of websites over the years, all of them using SSR (or HTML templates as we called them back in the day). I've personally never written a JavaScript-native website. I'm not saying the above because I built a career on writing JS or something. And despite that, I completely understand why devs might refuse to support non-JS browsers. It's a lot of extra work, it means they can't use the "modern" (React launched in 2013) tools they're use to, and all without any compelling financial benefit.
Of note here is that the segment we're talking about is actually an intersection of two very small cohorts; the first, as you note, are people who don't own a television errr disable Javascript, and the second is sites that actually rely on XSLT, of which there are vanishingly few.
The "severe security issue" in libxml2 they mention is actually a non-issue and the code in question isn't even used by Chrome. I'm all for switching to memory-safe languages but badmouthing OSS projects is poor style.
Google is too cheap to fund or maintain the library they've built their browser with after its hobbyist maintainers got burnt out, for more than a decade so they're ripping out the feature.
Their whole browser is made up of unsafe languages and their attempt to sort of make c++ safer has yet to produce a usable proof of concept compiler. This is a fat middle finger in the face of all the people's free work they grabbed to collect billions for their investors.
Sounded like the maintainers of libxml2 have stepped-back, so there needs to be a supported replacement, because it is widely used. (Or if you are worried the reputation of "OSS", you can volunteer!)
The issue in question is just one of the several long-unfixed vulnerabilities we know about, from a library that doesn't have that many hands or eyes on it to begin with.
And why doesn’t Google contribute to fixing and maintaining code they use?
Because they don't want to use the code. They begrudgingly use it to support XSLT and now they don't use it.
Maintaining web standards without breaking backwards compatibility is literally what they signed up for when they decided to make a browser. If they didn't want to do that job, they shouldn't have made one.
Because in this case it doesn't contribute to their ability to deliver ads.
Nobody is badmouthing open source. It's the core truth, open source libraries can become unmaintained for a variety of reasons, including the code base becoming a burden to maintain by anyone new.
And you know what? That's completely fine. Open source doesn't mean something lives forever
Where's the best collection or entry point to what you've written about Chrome's use of Gnome's XML libraries, the maintenance burden, and the dearth of offers by browser makers foot the bill?
Makes me kind of sad. I started my carrier back in days when XHTML and co were lauded as the next thing. I worked with SOAP and WDSLs. I loved that one can express nearly everything in XML. And namespaces… Then came json and apart from being easier to read for humans I wondered why we switch from this one great exchange format to this half baked one. But maybe I’m just nostalgic. But every time I deal with json parsers for type serialization and the question how to express HashMaps and sets, how to provide type information etc etc I think back to XML and the way that everything was available on board. Looked ugly as hell though :)
That's upsetting. Being able to do templating without using JavaScript was a really cool party trick.
I've used it in an unfinished website where all data was stored in a single XML file and all markup was stored in a single XSLT file. A CGI one-liner then made path info available to XSLT, and routing (multiple pages) was achieved by doing string tests inside of the XSLT template.
"Removing established open standards for a more walled garden" -> Fixed
To those who saw a chrome.com link and got triggered:
> The Firefox[^0] and WebKit[^1] projects have also indicated plans to remove XSLT from their browser engines.
[^0]: https://github.com/mozilla/standards-positions/issues/1287#i...
[^1]: https://github.com/whatwg/html/issues/11523#issuecomment-314...
In my opinion this is not “we agree lets remove it”. This is “we agree to explore the idea”.
Google and Freed using this as a go ahead because the Mozilla guy pasted a pollyfill. However it is very clearly NOT an endorsement to remove it, even though bad actors are stating so.
> Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support1. If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance.
Freed et al also explicitly chose to ignore user feedback for their own decision and not even try to improve XSLT security issues at the cost of performance.
Last I heard for WebKit removing it was the only outcome they saw.
Yeah all these billion dollar corporations that can’t be bothered see it as the only path forward not because of technological or practical issues, but because none of them can be asked to give a shit and plan it into their budgets.
They’re MBAs who only know how to destroy and consolidate as trained.
I get the frustration but I don’t believe that’s really accurate. It’s not widely used and modern developers don’t see it as valuable.
XSLT in the browser was left fundamentally underdeveloped, which is why it is not really widespread.
XSLT in non-browser contexts is absolutely valuable.
I’m a modern developer and I see it as valuable. Why side with the browser teams and ignoring user feedback?
If “modern developers” actually spent time with it, they’d find it valuable. Modern developers are idiots if their constant cry is “just write it in JS”.
No idea what’s inaccurate about this. A billion dollar company that has no problem pivoting otherwise, can’t fund open technology “because budgets” is simply a lie.
The dominant user feedback is the hard statistics on how rarely it's used.
You can't trim the space of "users" to just "people who already adopted the technology" in the context of the cost of browser support.
“Everyone who uses the blink tag agrees it’s critical functionality.”
If you are using XSLT to make your RSS or atom feeds readable in a browser should somebody click the link you may find this post by Jake Archibald useful: https://jakearchibald.com/2025/making-xml-human-readable-wit... - it provides a JavaScript-based alternative that I believe should work even after Chrome remove this feature.
As someone who built an XSLT renderer and remembers having an awful time with the spec: good riddance.
Data and its visualisation should be strictly separate, and not require an additional engine in your environment of choice.
So XPath locators won't be available in Playwright and Selenium in Chrome? This could be huge for QA and RPA.
They are still keeping the XPath APIs so XPath locators will still work.
I to this day think the move from dsssl to xslt was the biggest mistake in the SGML to XML evolution.
they went from a clean scheme based standard to a human-unreadable "use a GUI tool" syntax.
st text serna was a wysiwyg XML FO rendering editor: throw in call stylesheets and some input XML, wysiwyg edit away
but xslt didn't take off nor did derived products.
Ah, so this is removing libxslt. For a minute I thought XSLT processing was provided by libxml2, and I remembered seeing that the Ladybird browser project just added a dependency on libxml2 in their latest progress update https://ladybird.org/newsletter/2025-10-31/.
I'm curious to see what happens going forward with these aging and under-resourced—yet critical—libraries.
I think that's sad. XSLT is in my point a view a very misunderstood technology. It gets hated on a lot. I wonder if this hate is by people who actually used and understood it, though. In any case, more often than not this is by people who in the same sentence endorse JavaScript (which, by any objective way of measuring is just a language far more poorly designed).
Iterating upon a JSON in raw JS is much sexier than learning XSLT. (at least, JS allows breakpoints in the Chrome debugger)
What does XSLT provide that you cannot achieve with plain JS?
I'm not much of a programmer, but XSLT being declarative means that I can knock out a decent-looking template without having to do a whole lot of programming work.
Au contraire: the more you understand and use XSLT, the more you hate it. People who don't understand it and haven't used it don't have enough information and perspective to truly hate it properly. I and many other people don't hate XSLT out of misunderstanding at all: just the opposite.
XSLT is like programming with both hands tied behind your back, or pedaling a bicycle with only one leg. For any non-trivial task, you quickly hit a wall of complexity or impossibility, then the only way XSLT is useful is if you use Microsoft's non-standard XSLT extensions that let you call out to JavaScript, then you realize it's so easy and more powerful to simply do what you want directly in JavaScript there's absolutely no need for XSLT.
I understand XSLT just fine, but it is not the only templating language I understand, so I have something to compare it with. I hate XSLT and vastly prefer JavaScript because I've known and used both of them and other worse and better alternatives (like Zope Page Templates / TAL / METAL / TALES, TurboGears Kid and Genshi, OpenLaszlo, etc).
https://news.ycombinator.com/item?id=44396067
https://news.ycombinator.com/item?id=22264623
https://news.ycombinator.com/item?id=28878913
https://news.ycombinator.com/item?id=16227249
>My (completely imaginary) impression of the XSLT committee is that there must have been representatives of several different programming languages (Lisp, Prolog, C++, RPG, Brainfuck, etc) sitting around the conference table facing off with each other, and each managed to get a caricature of their language's cliche cool programming technique hammered into XSLT, but without the other context and support it needed to actually be useful. So nobody was happy!
>Then Microsoft came out with MSXML, with an XSL processor that let you include <script> tags in your XSLT documents to do all kinds of magic stuff by dynamically accessing the DOM and performing arbitrary computation (in VBScript, JavaScript, C#, or any IScriptingEngine compatible language). Once you hit a wall with XSLT you could drop down to JavaScript and actually get some work done. But after you got used to manipulating the DOM in JavaScript with XPath, you being to wonder what you ever needed XSLT for in the first place, and why you don't just write a nice flexible XML transformation library in JavaScript, and forget about XSLT.
Counterpoint: the more I used XSLT, the more I liked it, and the more I was frustrated that the featureset that ships in browsers is frozen in 1999
You should really try some of the modern alternatives. Don't let Angular and React's templating systems poison you, give Svelte a try!
Even just plain JavaScript is much better and more powerful and easier to use than XSLT. There are many JavaScript libraries to help you with templates. Is there even any such thing as an XSLT library?
Is there some reason you would prefer to use XSLT than JavaScript? You can much more easily get a job yourself or hire developers who know JavaScript. Can you say the same thing for XSLT, and would anyone in their right mind hire somebody who knows XSLT but refuses to use JavaScript?
XSLT is so clumsy and hard to modularize, only good for messy spaghetti monoliths, no good for components and libraries and modules and frameworks, or any form of abstraction.
And then there's debugging. Does a good XSLT debugger even exist? Can it hold a candle to all the off-the-shelf built-in JavaScript debuggers that every browser includes? How do you even debug and trace through your XSLT?
It is always correct to tell someone they are wrong for liking something, and doing so is how we keep HN great.
I know it makes me an old and I am biased because one of the systems in my career I am most proud of I designed around XSLT transformations, but this is some real bullshit and a clear case why a private company should not be the de facto arbiter of web standards. Have a legacy system that depends on XSLT in the browser? Sucks to be you, one of our PMs decided the cost-benefit just wasn't there so we scrapped it. Take comfort in the fact our team's velocity bumped up for a few weeks.
And yes I am sour about the fact as an American I have to hope the EU does something about this because I know full-well it's not happening here in The Land of the Free.
It wasn't clear to me from reading this whether
with CSS will also stop being supported. There's no need to deprecate that, surely?Previous discussion https://news.ycombinator.com/item?id=44952185
I don't use XSLT and don't object to this, but seeing "security" cited made me realize how reflexively distrustful I've become of them using that justification for a given decision. Is this one actually about security? Who knows!
Didn't this come pretty directly after someone found some security vulns? I think the logic was, this is a huge chunk of code that is really complex which almost nobody uses outside of toy examples (and rss feeds). Sure, we fixed the issue just reported, but who knows what else is lurking here, it doesn't seem worth it.
As a general rule, simplifying and removing code is one of the best things you can do for security. Sure you have to balance that with doing useful things. The most secure computer is an unplugged computer but it wouldn't be a very useful one; security is about tradeoffs. There is a reason though that security is almost always cited - to some degree or another, deleting code is always good for security.
> As a general rule, simplifying and removing code is one of the best things you can do for security.
Sure, but that’s not what they’re doing in the big picture. XSLT is a tiny drop in the bucket compared to all the surface area of the niche, non-standard APIs tacked onto Chromium. It’s classic EEE.
https://developer.chrome.com/docs/web-platform/
My understanding is that contrary to popular opinion it is firefox not chrome that originally pushed for the removal, so i dont know how relavent that is. It seems like all browser vendors are in agreement on xslt.
that said, xslt is a bit of a weird api in how it interacts with everything. Not all apis are equally risky and i suspect xslt is pretty high up there on the risk vs reward ratio.
There are security issues in the C implementation they currently use. They could remove this without breaking anything by incorporating the JS XSLT polyfill into the browser. But they won't because money.
> Finding and exploiting 20-year-old bugs in web browsers
> 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
> libxslt -- unmaintained, with multiple unfixed vulnerabilities
— https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99...
Its "Security" when they want to do a thing, its "WebCompat" when they don't.
Would it be possible to move it to an add-on for those who still want it? Are WebExtensions supporting third-party-libs?
> When that solution isn't wanted, the polyfill offers another path.
A solution is only a solution if it solves the problem.
This sort of thing, basically a "reverse X/Y problem", is an intellectually dishonest maneuver, where a thing is dubbed a "solution" after just, like, redefining the problem to not include the parts that make it a problem.
The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke.
> As mentioned previously, the RSS/Atom XML feed can be augmented with one line, <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>, which will maintain the existing behavior of XSLT-based transformation to HTML.
Oh, yeah? It's that easy? So the Chrome team is going to ship a solution where when it encounters un-un-fucked content that depends on XSLT, Chrome will transparently fix it up as if someone had injected this polyfill import into the page, right? Or is this another instance where well-paid engineers on the Chrome team who elected to accept the responsibility of maintaining the stability of the Web have decided that they like the getting-paid part but don't like the maintaining-the-stability-of-the-Web part and are talking out of both sides of their mouths?
> So the Chrome team is going to ship a solution where when it encounters un-un-fucked content that depends on XSLT, Chrome will transparently fix it up as if someone had injected this polyfill import into the page, right?
As with most things on the web, the answer is "They will if it breaks a website that a critical mass of users care about."
And that's the issue with XSLT: it won't.
Removing JavaScript for a more secure browser.
TIL: Chrome supports XSLT.
Good riddance I guess - it and most of the tech from the "XML era" was needlessly overcomplicated.
Your response is like seeing the cops going to the wrong house to kick in your neighbors door, breaking their ornaments in their entry way, and then saying to yourself, "Good. I hate yellow, and would never have any of that tacky shit in my house."
As your first sentence of your comment indicates, the fact that it's supported and there for people to use doesn't (and hasn't) result in you being forced to use it in your projects.
Yes but software, and especially browser, complexity has balooned enormously over the years. And while XSLT probably plays a tiny part in that, it's likely embedded in every Electron app that could do in 1MB what it takes 500 MB to do, makes it incrementally harder to build and maintain a competing browser, etc., etc. It's not zero cost.
I do tend to support backwards compatibility over constant updates and breakage, and needless hoops to jump through as e.g. Apple often puts its developers through. But having grown up and worked in the overexuberant XML-for-everything, semantic-web 1000-page specification, OOP AbstractFactoryTemplateManagerFactory era, I'm glad to put some of that behind us.
If that makes me some kind of gestappo, so be it.
Remove crappy JS APIs and other web-tech first before deprecating XSLT - which is a true-blue public standard. For folks who don't enable JS and XML data, XSLT is a life-saver.
Perhaps, but isn't the contemporary tech stack orders of magnitude more complicated? Doesn't feel like a strong motivating argument.
XSLT is really powerful and it is declarative, like CSS, but can both push and pull.
It's a loss, if you ask me, to remove it from client-side, but it's one I worked through years ago.
It's still really useful on the server side for document transformation.
Imagine a WASM XSLT interpreter wouldn't be to hard to compile?
TFA mentions polyfills and libraries.
Unquestionably the right move. From the various posts on HN about this, it's clear that (A) not many people use it (B) it increases security vulnerability surface area (C) the few people who do claim to use have nothing to back up the claim
The major downside to removing this seems to be that a lot of people LIKE it. But eh, you're welcome to fork Chromium or Firefox.
Chrome and other browsers could virtually completely mitigate the security issues by shipping the polyfil they're suggesting all sites depending on XSLT deploy in the browser. By doing so, their XSLT implementation would become no less secure than their javascript implementation (and fat chance they'll remove that). The fact that they've rejected doing so is a pretty clear indication that security is just an excuse, IMO.
Pour one out for @vgr-land https://news.ycombinator.com/item?id=45006098
what exactly is the security concern with xslt?
It parses untrusted input, the library is basically unmaintained, it’s not often audited but anytime someone looks they find a CVE.
This is answered in the article.
XSLT the idea contains few (but not zero) unavoidable security flaws.
libxslt the library is a barely-maintained dumpster fire of bad practices.
They should audit LLMs.
"The reality is that for all of the work that we've put into HTML, and CSS, and the DOM, it has fundamentally utterly failed to deliver on its promise.
It's even worse than that, actually, because all of the things we've built aren't just not doing what we want, they're holding developers back. People build their applications on frameworks that _abstract out_ all the APIs we build for browsers, and _even with those frameworks_ developers are hamstrung by weird limitations of the web."
- https://news.ycombinator.com/item?id=34612696#34622514
I find it so weird that browser devs can point to the existence of stuff like React and not feel embarrassed.
> I find it so weird that browser devs can point to the existence of stuff like React and not feel embarrassed.
Sorry, I don't follow. What's embarrassing about React?
Nice find — interesting to see browsers moving to drop XSLT support. I used XSLT once for a tiny site and it felt like magic—templating without JavaScript was freeing. But maybe it’s just niche now, and browser vendors see more cost than payoff.
Curious: have any of you used XSLT in production lately?
Yes. It's used heavily in the publishing and standards industries that store the documents in JATS and other XML-based formats.
Because browsers only support XSLT 1.0 the transform to HTML is typically done server side to take advantage of XSLT 2.0 and 3.0 features.
It's also used by the US government:
1. https://www.govinfo.gov/bulkdata/BILLS
2. https://www.govinfo.gov/bulkdata/FR/resources
I lead a team that manage trade settlements for hedge funds; data is exported from our systems as XML and then transformed via XSLT into whatever format the prime brokers require.
All the transformed are maintained by non-developers, business analysts mainly. Because the language is so simple we don't need to give them much training, just get IntelliJ installed on their machine, show them a few samples and let them work away.
We couldn't have managed with anything else.
Destroying the open web instead of advocating to fix one of the better underutilized browser technologies for a more Profitable Google.
I will not forget the name Mason Freed, destroyer of open collaborative technology.
Didn't this effort start with Mozilla and not Google? I think you will in fact forget the name Mason Freed, just like most of us forgot about XSLT.
> Didn't this effort start with Mozilla and not Google?
Maybe round one of it like ten years ago did? From what I understand, it's a Google employee who opened the "Hey, I want to get rid of this and have no plans to provide a zero-effort-for-users replacement." Github Issue a few months back.
> It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it.
— https://news.ycombinator.com/item?id=44953349
I don't see any evidence of that claim from the materials I have available to me. [0] is the Github Issue I mentioned. [1] is the WHATNOT meeting notes linked to from that GH Issue... though I have no idea who smaug is.
[0] <https://github.com/whatwg/html/issues/11523>
[1] <https://github.com/whatwg/html/issues/11146#issuecomment-275...>
Smaug is the Mozilla engineer they were talking about:
https://github.com/smaug----
Ah, that was my problem... I didn't put enough minuses after the nickname. ;)
You can remember their name forever now!
You appear to have forgotten how to scroll up and notice that the name of the OP is not my name. ;)
No, I know, I'm just being silly. Sorry, I didn't mean to attribute that sentiment to you.
Blame Apple and Mozilla, too, then. They all agreed to remove it.
They all agreed because XSLT is extremely unpopular and worse than JS in every way. Performance/bloat? Worse. Security? MUCH worse. Language design? Unimaginably worse.
EDIT: I wrote thousands of lines of XSLT circa 2005. I'm grateful that I'll never do that again.
This is only repeated by people who have never used it.
XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).
I used to use XSLT a lot, though it was a while ago.
You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code.
Do you have a particular example where you think Javascript might be more verbose than XSLT?
I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty.
Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!
It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...
I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every popular CI system for "YAML is not a programming language".
That doesn't mean that XML isn't useful. Just not as a programming language.
But, that's what XSL is! XSL is a Turing-complete programming language in XML for processing XML documents. Being in XML is a big part of what makes XSL so awful to write.
XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages.
Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.
> It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...
npm isn't even a build tool, it's a package manager and at that it's actually gotten quite decent - the fact that the JS ecosystem at large doesn't give a fuck about respecting semantic versioning or keeps reinventing the wheel or that NodeJS / JavaScript itself lacks a decent standard library aren't faults of npm ;)
Maven and Gradle in contrast are one-stop-shops, both build orchestrators and dependency managers. As for ant, oh hell yes I'm aware of that. The most horrid build system I encountered in my decade worth of tenure as "the guy who can figure out pretty much any nuclear submarine project (aka, only surfaces every few years after everyone working on it departed)" involved Gradle, which then orchestrated Maven and Ant, oh and the project was built on a Jenkins that was half DSL, half clicked together in the web UI, and the runner that executed the builds was a manually set up, "organically grown" server. That one was a holy damn mess to understand, unwind, clean up and migrate to Gitlab.
> look at pretty much every popular CI system for "YAML is not a programming language".
Oh yes... I only had the misfortune of having to code for Github Actions once in my life time, it's utter fucking madness compared to GitLab.
> Security? MUCH worse.
Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense.
Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)
If you would RTFA, they're removing XSLT specifically for security reasons. They provide the following links:
https://www.offensivecon.org/speakers/2025/ivan-fratric.html
> 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://nvd.nist.gov/vuln/detail/CVE-2025-7425
https://nvd.nist.gov/vuln/detail/CVE-2022-22834
(And, for the record, XSL is Turing-complete. It has xsl:variable, xsl:if, xsl:for-each, and xsl:apply-template function calls.)
Are the security concerns not about libxslt, rather than XSLT?
How is it worse than JS? It's a different thing...
> They all agreed to remove it.
All those people suck, too.
Were you counting on a different response?
> XSLT is extremely unpopular and worse than JS in every way
This isn't a quorum of folks torpedoing a proposed standard. This is a decades-old stable spec and an established part of the Web platform, and welching on their end of the deal will break things, contra "Don't break the Web".
You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.
They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons.
Only Google is pushing forward and twisting that message.
> They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons.
Mozilla:
> Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support.
— https://github.com/mozilla/standards-positions/issues/1287#i...
WebKit:
> WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support, though if there's a known list of origins that participate in a reverse origin trial we could perhaps participate sooner.
— https://github.com/whatwg/html/issues/11523#issuecomment-314...
Describing either of those as “they preferred to keep it” is blatantly untrue.
> Destroying the open web instead of advocating to fix one of the better underutilized browser technologies for a more Profitable Google.
Google, Mozilla and Apple do not care if it doesn't make them money, unless you want to pay them billions to keep that feature?
> I will not forget the name Mason Freed, destroyer of open collaborative technology.
This is quite petty.
XSLT is complete and utter garbage. Good riddance.
Good, XSLT was crap. I wrote an RSS feed XSLT template. Worst dev experience ever. No one is/was using XSLT. Removing unused code is a win for browsers. Every anti bloat HNer should be cheering
I'm always puzzled by statements like this. I'm not much of a programmer and I wrote a basic XSLT document to transform rss.xml into HTML in a couple of hours. I didn't find it very hard at all (anecdotes are not data, etc)
The first few times you use it, XSLT is insane. But once something clicks, you figure out the kinds of things it’s good for.
I am not really a functional programming guy. But XSLT is a really cool application of functional programming for data munging, and I wouldn’t have believed it if I hadn’t used it enough for it to click.
XSLT's matching rules allow a 'push' style of transform that's really neat. But you can actually do that with any programming language such as Javascript.
Right. I didn't use it much on the client side so I am not feeling this particular loss so keenly.
But server side, many years ago I built an entire CMS with pretty arbitrary markup regions that a designer could declare (divs/TDs/spans with custom attributes basically) in XSLT (Sablotron!) with the Perl binding and a customised build of HTML Tidy, wrapped up in an Apache RewriteRule.
So designers could do their thing with dreamweaver or golive, pretty arbitrarily mark up an area that they wanted to be customisable, and my CMS would show edit markers in those locations that popped up a database-backed textarea in a popup.
What started off really simple ended up using Sablotron's URL schemes to allow a main HTML file to be a master template for sub-page templates, merge in some dynamic functionality etc.
And the thing would either work or it wouldn't (if the HTML couldn't be tidied, which was easy enough to catch).
The Perl around the outside changed very rarely; the XSLT stylesheet was fast and evolved quite a lot.
> Every anti bloat HNer should be cheering
Actually a transformation system can reduce bloat, as people don't have to write their own crappy JavaScript versions of it.
Being XML the syntax is a bit convoluted, but behind that is a good functional (in sense of functional programming language, not functioning) system which can be used for templating etc.
The XML made it a bit hard to get started and anti-XML-spirit reduced motivation to get into it, but once you know it, it beats most bloaty JavaScript stuff in that realm by a lot.
> No one is/was using XSLT.
Ah, when ignorance leads to arrogance; It is massively utilised by many large entreprise or state administration in some countries.
Eg if you're american the library of congress uses it to show all legislative text.
Although it's sad to see an interesting feature go, they're not wrong about security. It's more important to have a small attack surface if this was maintained by one guy in Nebraska and he doesn't maintain it any more.
No, XSLT isn't required for the open web. Everything you can do with XSLT, you can also do without XSLT. It's interesting technology, but not essential.
Yes, this breaks compatibility with all the 5 websites that use it.