> One extremely important...

Not to downplay what you think is important, but I think it's pretty important that governments and public bodies use XSLT.

https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih....

https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL...

https://www.weather.gov/xml/current_obs/KABE.xml

https://www.europarl.europa.eu/politicalparties/index_en.xml

https://apps.tga.gov.au/downloads/sequence-description.xml

https://cwfis.cfs.nrcan.gc.ca/downloads/fwi_obs/WeatherStati...

https://converters.eionet.europa.eu/xmlfile/EPRTR_MethodType...

They don't put ads on their sites, so I'm not surprised Google doesn't give a fuck about them...

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.

Another use case I discovered and implemented many years ago was styling a sitemap.xml for improved UX / aesthetics.

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

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:

    text/html,application/xhtml+xml,application/xml;
    q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8

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 never realized styling RSS feeds was an options. Now looking at some of the examples, I wonder how many times I've clicked on "Feed", then rolled my eyes and closed it because I thought it wasn't RSS. More than zero, I'm sure.

It's the right direction if you're google. This is why Google should not be allowed to control the web. Support firefox, dump google.

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

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

100%. I’ve been neck deep over the past few months in developing a bunch of Windows applications, and it’s convinced me that never deprecating or removing anything in the name of backwards incompatibility is the wrong way. There’s a balance to be struck like anything, but leaving these things around means we continue to pay for them in perpetuity as new vulnerabilities are found or maintenance is required.

What about XML + CSS? CSS works the exact same on XML as it does on HTML. Actually, CSS works better on XML than HTML because namespace prefixes provide more specific selectors.

The reason CSS works on XML the same as HTML is because CSS is not styling tags. It is providing visual data properties to nodes in the DOM.

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.

> 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

Some people seem to think XSLT is used for the step from DOM -> Graphics. This is not the first time I have send a comment implying that, but it is wrong. XSLT is for the step from 'normalized data' -> DOM. And I like it, that this can be done in a declarative way.

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!

Best thread IMHO, lots of thoughtful root-level comments:

"Remove mentions of XSLT from the html spec" https://news.ycombinator.com/item?id=44952185

It is also kinda a self-burn. Chromium an aging code base [1]. It is written in a memory unsafe language (C++), calls hundreds of outdated & vulnerable libraries [2] and has hundreds of high severity vulnerabilities [3].

People in glass houses shouldn't throw stones.

[1] https://github.com/chromium/chromium/commits/main/?after=c5a...

[2] https://github.com/chromium/chromium/blob/main/DEPS

[3] https://www.cvedetails.com/product/15031/Google-Chrome.html?...

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.

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.

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!)

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?

XSLT is being exploited right now for security vulnerabilities, and there is no solution on the horizon.

The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators.

You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tomfoolery, and from the beginning there were loopholes to introduce unsafe code.

As they say, security is not a product, it’s a process. The process we have for existing browser technologies is better. That process is better because more people use it.

But even if we were to try to consider the technologies in isolation, and imagine a timeline where things were different? I doubt whether XML+XSLT is the superior platform for security. If it had won, we’d just have a different nightmare of intermingled content and processing. Maybe more stuff being done client-side. I expect that browser and OS manufacturers would be warping content to insert their own ads.

> 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 feel like there's a bias here due to XSLT being negletted and hence not receiving the same powers as JS. If it did get more development in the browser I'm pretty sure it would get the same APIs that we hate JS for, and since it's already Turing complete chances are people will find ways to misuse it and bloat websites.

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

json is sort of a gresham's law "bad money drives out the good" but for tech: lazy and forgiving technologies drive out the better but stricter ones.

bad technology seems to make life easier at the beginning, but that's why we now have sloppy websites that are an unorganized mess of different libraries, several MB in size without reason, and an absolute usability and accessibility nightmare.

xhtml and xml were better, also the idea separating syntax from presentation, but they were too intelligent for our own good.

IMO XSLT was just too difficult for most webdevs. And IMO this created a political problem where the 'frontend' folks needed to be smarter than the 'backend' generating the XML in the first place.

XSLT might make sense as part of a processing pipeline. But putting it on front of your website was just an unnecessary and inflexible layer, so that's why everyone stopped doing it. (except rss feeds and etc.)

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?

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.

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.

They are still keeping the XPath APIs so XPath locators will still work.

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.

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.

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

It's true that there are security issues, but it's also true that they don't want to put any resources into making their XSLT implementation secure. There is strong unstated subtext that a huge motivation is that they simply want to rip this out of Chrome so they don't have to maintain it at all.

Especially when Google largely has the money to maintain the alleged unsecure library... of course it's an excuse to break the web once again.

XSLT is fantastic. You just feed it an XML file and it can change it into HTML, without any need for javascript.

> example.com needs to review the security of your connection before proceeding.

This text from Cloudflare challenge pages is just a flat-out lie.

Its "Security" when they want to do a thing, its "WebCompat" when they don't.

The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.

I do all of my browsing with Javascript disabled. I've done this for decades now, as a security precaution mainly, but I've also enjoyed some welcome side-effects where paywalls disappeared and ads became static and unobtrusive. I wasn't looking for those benefits but I'll take 'em. In stride.

I've also witnessed a welcome (but slow) change in site implementations over the years: there are few sites completely broken by the absence of JS. Still some give blank screens and even braindead :hidden attributes thrown into the <noscript> main page to needlessly forbid access... but not as many as back in the day when JS first became the rage.

I don't know much about XSLT other than the fact that my Hiawatha web server uses it to make my directory listings prettier, and I don't have to add CSS or JS to get some style. I hate to see a useful standard abandoned by the big boys, but what can I do about it?

I bristle when I encounter pages with a few hundred words of content surrounded by literally megabytes of framework and flotsam, but that's the gig, right, wading through the crap to find the ponies.

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

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.

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.

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.

"[Y]ou're welcome to fork Chromium or Firefox" is the software developer equivalent of saying "you're welcome to go fuck yourself."

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.

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.

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.

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

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

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.

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.

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

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)