To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser. The polyfill is located on GitHub or as an npm package:

• https://github.com/mfreed7/xslt_polyfill
• https://www.npmjs.com/package/xslt-polyfill

This contains a functional polyfilled replacement for the XSLTProcessor class, plus a utility function for an easy way to replace XML documents that use XSLT processing instructions. Of course, XSLT would also continue to be executable on the server side if needed.

@smaug----, @annevk, @emilio, @rniwa for thoughts

* https://www.npmjs.com/package/interestfor

Wrong one right? But in general I think removing XSLT is worth trying, given the attack surface vs. usage trade-off.

This other metric shows less of a decline, and 20x more usage than the metric linked to above. Just saying.

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.

It might also make sense to coordinate on a console warning?

I think this is definitely worth trying. And yes, hopefully this time all the browsers could add a console warning sooner than later (that might reduce the risk to what happened with Mutation Events, where deprecation was discussed and kind of agreed on 2011-12, but removal happened 2025 ;) Only some browsers had the warning.)

Out of curiosity, what is the game plan for displaying RSS feeds pleasantly when removing this?

As a web developer and user, hard disagree on the proposal.

Just because something can be implemented in JS it doesn't mean that native solutions should be removed. One of the powers of XSLT support in browsers is that it can be used even with JS disabled, and in terms of security for the user, JS is a much bigger attack surface than XSL.

Both the antiquated XSLT version and the safety of the implementation can be addressed by adopting (and contributing to the development of) newer libraries written in safer languages, such as xrust.

To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser.

Could Chrome ship a package like this instead of using native XSLT code, to address some of the security concerns? (I'm thinking about how Firefox renders PDFs without native code using PDF.js.)

Wrong one right?

Gah - sorry. Too many polyfills. I've updated that comment with the correct link.

in general I think removing XSLT is worth trying, given the attack surface vs. usage trade-off.

Awesome, thanks for the comment.

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.

Great news, thanks. I understand the desire to wait for origin trials to expire or otherwise make sure sites aren't broken during the migration process. For Chrome at least, I doubt I can share the list, but I can definitely ask around to see if that's true.

It might also make sense to coordinate on a console warning?

I agree, great idea!

I think this is definitely worth trying.

Great, thank you.

And yes, hopefully this time all the browsers could add a console warning sooner than later

Makes sense to me!

Out of curiosity, what is the game plan for displaying RSS feeds pleasantly when removing this?

This is a great point, and is likely the largest source of current usage. My thought had been that perhaps some version of the polyfill could be used to continue using XSLT to format a feed?

As a web developer and user, hard disagree on the proposal.

Understood, and thanks for the feedback!

Just because something can be implemented in JS it doesn't mean that native solutions should be removed. One of the powers of XSLT support in browsers is that it can be used even with JS disabled, and in terms of security for the user, JS is a much bigger attack surface than XSL.

I think the issue with XSLT isn't necessarily the size of the attack surface, it's the lack of attention and usage. I.e. nearly 100% of sites use JS, while 1/10000 of those use XSLT. So all of the engineering energy (rightfully) goes to JS, not XSLT.

Both the antiquated XSLT version and the safety of the implementation can be addressed by adopting (and contributing to the development of) newer libraries written in safer languages, such as xrust.

Thanks for the pointer to xrust - I hadn't seen that one. Perhaps because it's quite recent. But we'll take a look.

To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser.

Could Chrome ship a package like this instead of using native XSLT code, to address some of the security concerns? (I'm thinking about how Firefox renders PDFs without native code using PDF.js.)

This is definitely something we have been thinking about. However, our current feeling is that since the web has mostly moved on from XSLT, and there are external libraries that have kept current with XSLT 3.0, it would be better to remove 1.0 from browsers, rather than keep an old version around with even more wrappers around them.

XSLT is extensively used by podcast hosting companies to beautify their raw feeds. Example:

https://feeds.buzzsprout.com/231452.rss

The Podcast Standards Project (@tomrossi7 @albertobeta @mijustin) would be a good source of engagement on this as to how this would affect their products. I imagine they represent a large percent of the overall public XSLT usage in the wild.

does the BBC still use XSLT to style RSS feeds as human viewable? that was a major point in the extensive 2013 discussion on this exact same suggestion
https://feeds.bbci.co.uk/news/rss.xml

EDIT adding a link to the 2013 discussion that was still getting pro-XSLT comments after 5 years
https://groups.google.com/a/chromium.org/g/blink-dev/c/zIg2KC7PyH0/m/Ho1tm5mo7qAJ

I analyzed usage of XSLT in httparchive (desktop pages that trigger the XSLProcessingInstruction use counter). This set will only pick up RSS randomly (because the non-root page is one of the linked pages from the root page, and only one non-root page per site is collected).

The number of matches is 357, out of ~23,000,000 pages (~0.001%).

There are a few pages that would be broken by removing XSLT (either some content in an iframe or the entire page or site). Some are education portals or application portals. Then there are a bunch of sitemaps, feeds, or API endpoints where the transform doesn't seem essential. From the pages I manually looked at and assessed impact, about 29% are primarily for humans and would have essential or main functionality broken if XSLT was removed (~104 of the 357 when extrapolating).

https://docs.google.com/spreadsheets/d/1ihvzeRpIcojGxXZ8rj4UQR0M3KY_c-mkkfn3C6Gkptg/edit?usp=sharing

@mfreed7

1. RSS and Atom Feeds: XSLT is used to make raw RSS and Atom feeds human-readable when viewed directly in a browser. The use case is that a user accidentally clicks on a site’s RSS feed link, rather than pasting that link into their RSS reader, and gets XML rather than something they can read.
   ➡ A proposal for this use case is to add <link rel="alternate" type="application/rss+xml"> to the (HTML-based) site, rather than an explicit (user-visible) <a href=”something.xml”> that users might accidentally click. This solution allows RSS readers to find the feed if a user pastes in just the website URL, but it also allows human users to see regular HTML content. This also follows the normal web paradigm that HTML is for humans and XML is for machines. Of course this doesn’t solve the case where a user just “has” an RSS link from somewhere, and they paste it into their web browser (rather than their RSS reader).

While doing my analysis (see above), I noticed that several of the feeds with XSLT have a helpful message at the top that explains what a feed is and what the user is expected to do with it (copy the URL into their feed reader or podcast player). This seems like something browsers could do (in place of the "this XML has no stylesheet" message for RSS and Atom).

I analyzed usage of XSLT in httparchive (desktop pages that trigger the XSLProcessingInstruction use counter). This set will only pick up RSS randomly (because the non-root page is one of the linked pages from the root page, and only one non-root page per site is collected).

The number of matches is 357, out of ~23,000,000 pages (~0.001%).

Wow awesome analysis, thank you. I'm taking some time to look through that list. I've already found a few cases where my browser extension fails, so I'll get those fixed.

While doing my analysis (see above), I noticed that several of the feeds with XSLT have a helpful message at the top that explains what a feed is and what the user is expected to do with it (copy the URL into their feed reader or podcast player). This seems like something browsers could do (in place of the "this XML has no stylesheet" message for RSS and Atom).

+1 to this idea. The only question is what the helpful message would be. I was thinking that the browser could detect an XML page that has an XSLT PI, and direct them (from the XML source viewer) to a browser extension. Better ideas appreciated.

P.S. For the other folks on this thread: while I am not the one who hid comments and closed this issue to non-collaborators, I completely agree with those actions. The ad hominem attacks here and elsewhere (e.g. this or this) violate the code of conduct and obscure the technical discussion. I'm just one engineer and I don't have unlimited budget; I'm just trying to do my job. I care a lot about the health of the overall web. I do want to find solutions to real problems, and I want to minimize the pain folks are feeling about this discussion of XSLT removal. But it's important to remember that ordinary users that fall victim to security vulnerabilities also feel pain, and I'm trying to minimize that too. I proposed some solutions to the concrete use cases I heard in this issue. If there are still gaps, I'd like to work on closing them. It's too bad we can't have that discussion here - I'm guessing we can't re-open this issue for outside comments, due to the overall tone of past comments. Either way, from now on, I'll only be responding to technical conversations, and ignoring the rest, for my own sanity.

@mfreed7 your polyfill requires putting a script in the XML markup. Is this likely to break feed readers that are not expecting that element?

I wonder if we could add a processing instruction to execute script, so it doesn't otherwise appear in the document.

@mfreed7 your polyfill requires putting a script in the XML markup. Is this likely to break feed readers that are not expecting that element?

Interesting question. I tried it with a handful of RSS readers and none of them reported any issues with a modified feed containing the polyfill <script> element. It seems like a <script> hanging right off the root is the least likely to cause problems, since it won't interfere with most XPath queries. But if there's a better place to put the script so that it's less likely to cause reader issues, that'd be good to know.

I wonder if we could add a processing instruction to execute script, so it doesn't otherwise appear in the document.

This is an option, of course. But if just tossing in the <script> doesn't seem to cause issues, then perhaps not necessary?

Fair. I just wonder if it'd close the feature gap. But if it's not a problem, it doesn't need a solution.

I guess we wouldn't want a new way to execute script, but the xslt processing instruction already can, so that might be a "way in"

I think we shouldn't add a new way to execute scripts. The main benefit would be theoretical purity of avoiding an HTML element in an XML document using a vocabulary that doesn't say you can use HTML elements.

I think we shouldn't add a new way to execute scripts.

Yeah, if anything, I was thinking <?xml-stylesheet type="text/javascript" href="transform.js"?>, since xml-stylesheet already results in script execution. But I agree, public feed readers tend to be non-validating, so it's ok to just add a <script>.