Removing XSLT from Chromium [LWN.net]

Mason Freed and Dominik Röttsches have published a document with a timeline and plans for removing Extensible Stylesheet Language Transformations (XSLT) from the Chromium project and Chrome browser:

Chromium has officially deprecated XSLT, including the XSLTProcessor JavaScript API and the XML stylesheet processing instruction. We intend to remove support from version 155 (November 17, 2026). The Firefox and WebKit projects have also indicated plans to remove XSLT from their browser engines. This document provides some history and context, explains how we are removing XSLT to make Chrome safer, and provides a path for migrating before these features are removed from the browser.

LWN covered the Web Hypertext Application Technology Working Group (WHATWG) discussion about XSLT in August.

to post comments

What about RSS?

Posted Nov 5, 2025 18:24 UTC (Wed) by oliwarner (subscriber, #81320) [Link] (26 responses)

I use XSLT stylesheets to render RSS for users without a feed reader, which is most people since Google removed built-in RSS processing.

It's getting harder to keep RSS alive.

What about RSS?

Posted Nov 5, 2025 18:52 UTC (Wed) by cen (subscriber, #170575) [Link] (4 responses)

Most people don't read RSS at all, they just import it into some other application.

What about RSS?

Posted Nov 5, 2025 19:02 UTC (Wed) by jzb (editor, #7867) [Link] (3 responses)

One of the cases made for keeping XSLT was -- I'm summarizing heavily here -- that a number of people stumble on RSS feeds without knowing what they are. Getting a mess of unstyled XML in the browser is not a good experience and does not help with RSS adoption. Some folks publish XSLT stylesheets that provide a readable view of the RSS feed and guidance on pulling that into a reader.

What about RSS?

Posted Nov 5, 2025 19:25 UTC (Wed) by josh (subscriber, #17465) [Link] (1 responses)

We should fix browsers to detect RSS and Atom, and put a standardized header at the top rather than raw XML. "This is a news feed, for use in a feed reader. You should open this URL in a feed reader that understands RSS."

What about RSS?

Posted Nov 11, 2025 16:29 UTC (Tue) by nye (guest, #51576) [Link]

> We should fix browsers to ...

That feature used to exist and was explicitly removed because Google aggressively hate RSS, open standards, puppies, and anything good or pure in the universe.

Good luck getting them to bring back a feature that somebody might actually want.

What about RSS?

Posted Nov 5, 2025 19:28 UTC (Wed) by zdzichu (subscriber, #17118) [Link]

This has zero impact on "RSS adoption". There's no such thing. The adoption phase is long gone, and we are in RSS decline.

That's the truth, even if we dislike it. Heh, I got mildly angry lately because Netvibes went to 💩 and I had to migrate to self-hosted Miniflux (which is cute, btw). I _just_ migrated to NV because Google Reader was killed!

Can't you use the Accept: request header?

Posted Nov 5, 2025 20:21 UTC (Wed) by Susko3 (guest, #179168) [Link] (6 responses)

It seems to me that you could use the Accept: HTTP header to disambiguate web browsers from RSS readers, and serve each different content.

For example, when I open a URL to an RSS feed in Firefox, my request headers are:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

And when I do it from Thunderbird it's:
Accept: application/atom+xml,application/rss+xml;q=0.9,application/rdf+xml;q=0.8,application/xml;q=0.7,text/xml;q=0.7,*/*;q=0.1

The web browser is clearly asking for an HTML file to show to the user, while the RSS reader is asking for an XML RSS feed. If you're always serving an XML RSS feed, you're ignoring the user agent's request.

Can't you use the Accept: request header?

Posted Nov 5, 2025 22:25 UTC (Wed) by fraetor (subscriber, #161147) [Link] (5 responses)

Having done a bit of reading into this, I think that although it is a shame to break existing sites in this way, it probably is the right thing to do. This kind of data format transformation should pretty much always be done on the server, IMO, so its not really surprising that none of the browser vendors have invested much into XSLT over the past 20 year, nor funded the underlying libraries. (https://lwn.net/Articles/1025971/)

RSS is the main motivator I've seen for this, with the others being a few old sites that are never going to be updated, and a few XML feeds from industrial equipment.

While adding specific handling of feeds to browsers would be ideal, content negotiation would be the way to implement something compatible now. Unfortunately some feed readers send text/html in their accept headers (often as they support scraping web pages that don't offer a feed), but if they don't list the atom/rss feeds as higher priority they are arguably broken, and it is the reader that should be fixed. Its a shame it will make the server side implementation of nice looking feeds more complex, but if it can be added to Wordpress that would cover a lot of feeds.

Static sites using dumb servers, like blogs on GitHub Pages, are probably going to be the hardest hit by this. I wonder if they would be best off having their visible RSS link actually go to a HTML page containing the real link with instructions on how to use a feed, along with a <link rel="alternate" type="application/atom+xml"> for any feeder readers given the HTML link. The article also suggests that you may be able to use a <script> tag in the XML to use the JavaScript polyfill in a directly served feed.

Can't you use the Accept: request header?

Posted Nov 5, 2025 22:56 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (3 responses)

That means having a costly server rather than just serving static files, just so that google can save some pennies.

Can't you use the Accept: request header?

Posted Nov 5, 2025 23:14 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

You can just serve a JS transformer along with the RSS feed. There are several available, e.g.: https://github.com/sdepold/vanilla-rss

Can't you use the Accept: request header?

Posted Nov 6, 2025 10:53 UTC (Thu) by jkingweb (subscriber, #113039) [Link] (1 responses)

This doesn't seem to actually solve the stated problem, because RSS and Atom are not scriptable. A browser confronted with an RSS feed would still see unformatted XML; you still need content negotiation, and all the complexity inherent in this.

Can't you use the Accept: request header?

Posted Nov 6, 2025 20:36 UTC (Thu) by fraetor (subscriber, #161147) [Link]

It looks like XML is however. There is a polyfill you can include in the feed XML via a script tag, which the browser will execute. See an example of how to use it at the following link:
https://github.com/mfreed7/xslt_polyfill?tab=readme-ov-fi...

I'm my testing it at least doesn't break the existing rendering, though I can't guarantee it is working, as I don't have a browser that doesn't support XSLT to fall back on it.

If you want something a bit lighter than a 1.5 MiB wasm compiled libxml2, you can rewrite the XML transformation directly in JavaScript, as demonstrated in the following blog post:
https://jakearchibald.com/2025/making-xml-human-readable-...

Can't you use the Accept: request header?

Posted Nov 6, 2025 19:43 UTC (Thu) by DemiMarie (subscriber, #164188) [Link]

Another option would be for static file servers to implement content negotiation. There can be multiple versions of the file available, and the server selects whichever one the client prefers. Nginx can already be configured to do this.

What about RSS?

Posted Nov 5, 2025 22:54 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (12 responses)

You have to understand that unfortunately google is a very tiny company and in no way they could sponsor a single developer that provides a very core library that they've been using for decades for free (/s).

What about RSS?

Posted Nov 10, 2025 5:32 UTC (Mon) by nirbheek (subscriber, #54111) [Link] (11 responses)

> very core library that they've been using for decades for free

I am not sure which part of your comment was sarcasm, but the fact that Chrome is willing and able to remove this feature in a year suggests that they weren't really "using" it as much as "letting it exist". It would be strange for them to fund a feature they don't need.

What about RSS?

Posted Nov 10, 2025 11:58 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (10 responses)

I think the point is that the feature has existed, and had users in the wild. Instead of supporting those users on the open internet, they decided to rip it out instead. Google does not maintain Chrome in a vacuum.

Really, I see a lot of parallels to the strategy that seems to be in effect elsewhere in the US at the moment…

What about RSS?

Posted Nov 10, 2025 12:34 UTC (Mon) by nirbheek (subscriber, #54111) [Link] (9 responses)

Having a few users in the wild has never been a reason for a project to support a feature. For example, GNOME could never stop support X11 if that were the criteria.

I've written a lot of XSLT for Beagle, and my first website (for a college festival) was written in XSLT, and we had a browser sponsor at the time (Opera) which didn't support it in their stable release(!). So I am in principle sympathetic to the XSLT cause. However, it's increasingly become a niche feature over time, and the userbase is insignificant.

Google's control over the Chromium project is a problem, but tbh XSLT support is something that even a community-managed browser would've reasonably decided to remove.

What about RSS?

Posted Nov 10, 2025 15:26 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (8 responses)

You seem to have chosen a terrible example since wayland is completely unusable by blind people and if DEs keep dropping support for X11 their only option seem to be to use windows, a thing that they might not be willing to do given how it comes with pre-installed spyware.

What about RSS?

Posted Nov 10, 2025 16:19 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

The problem is that the features *required* by most blind-assistance-software are a spyware-writer's wet dream.

Which is why any sane security-minded person doesn't want to implement them. (And no, Windows isn't any better on that front!)

How you square the circle on this I don't know, but the first thing you have to do is acknowledge the root cause of the problem - security and convenience usually conflict, and this is a mahousive example thereof! This is nothing whatsoever to do with Wayland, it's just sensible security.

Cheers,
Wol

What about RSS?

Posted Nov 10, 2025 21:33 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

Perhaps we could avoid the mobile phone app store model where 99% of what is there is malware and keep using the linux distribution with sane repository model where there is no malware and the software can actually be trusted?

What about RSS?

Posted Nov 10, 2025 17:04 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (5 responses)

Actual vision-impaired people disagree with you assessment: https://fireborn.mataroa.blog/blog/i-want-to-love-linux-i... (and other posts from this series).

What about RSS?

Posted Nov 10, 2025 21:30 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (1 responses)

https://news.ycombinator.com/item?id=45796885

What about RSS?

Posted Nov 10, 2025 21:56 UTC (Mon) by pizza (subscriber, #46) [Link]

> https://news.ycombinator.com/item?id=45796885

"I haven't used gnome recently but last time I tried it..." shows the general uselessness of that anectdote.

What about RSS?

Posted Nov 10, 2025 21:32 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (2 responses)

I read that post as "things are getting better", not as "things work just as well as on Xorg". The latter is the requirement.

What about RSS?

Posted Nov 11, 2025 7:48 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (1 responses)

From the post I've linked:

> Then I tried GNOME on Wayland.
> And… it works. Orca is responsive. Focus tracking behaves. That ancient modifier bug where Caps Lock would stick after Orca commands? Gone. That was an X problem — and Wayland fixes it.

In other words, Wayland works better than X11 already.

From the post you've linked:

> I haven't tried Gnome recently […] I've heard that Gnome has solved this

I do not feel like continuing this discussion, if you can't even refer to the links provided.

What about RSS?

Posted Nov 11, 2025 10:17 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

> In other words, Wayland works better than X11 already.

You are absolutely correct. People who complain about it are just completely insane and have not encountered any issue. Unfortunately mental illness can make people hallucinate bugs.

> I do not feel like continuing this discussion, if you can't even refer to the links provided.

I have a feeling you didn't fully read the link you provided.

What about RSS?

Posted Nov 12, 2025 15:51 UTC (Wed) by jwilk (subscriber, #63328) [Link]

You can use CSS to style XML documents. Not as powerful as XSL, but hey.

next: javascript!

Posted Nov 5, 2025 18:39 UTC (Wed) by ballombe (subscriber, #9523) [Link] (2 responses)

While they are at it, they should remove javascript support, this would make chromium much safer.

next: html!

Posted Nov 6, 2025 8:10 UTC (Thu) by comio (subscriber, #115526) [Link]

the root cause is the html at all. Gopher is safer alternative.

ciao

next: javascript!

Posted Nov 7, 2025 10:07 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

Google would not care less if it is useful or not, they want tech that serves ads and centralises snitching server (ideally cloud-provider) side. XSLT is not that. They want to be paid for advertising and they want to be paid for snitching (market monitoring and “helping” various agencies). Therefore XSLT is a dead weight, and JS tracking – not.