Can’t you just do the xslt transformation server-side? Then you can use the newest and best xslt tools, and the output will work in any browser, even browsers that never had any built-in xslt support.
> Cant you just do the xslt transformation server-side?
For my Atom feed, sure. I'm already special-casing browsers for my Atom feed [0], so it wouldn't really be too difficult to modify that to just return HTML instead. And as others mentioned, you can style RSS/Atom directly with CSS [1].
For my Stardew Valley Item Finder web app, no. I specifically designed that web app to work offline (as an installable PWA), so anything server-side won't work. I'll probably end up adding the JS/wasm polyfill [2] to that when Chrome finally removes support, but the web app previously had zero dependencies, so I'm a little bit annoyed that I'll have to add a 2MB dependency.
That is actually mozilla's stand in the linked issue except it's on client though. They would rather replace it with some non native replacement (So there is no surprising security issue anymore) if remove directly is impractical.
There is actually a example of such situation. Mozilla removed adobe pdf plugin support a long time ago and replaced it with pdf.js. It's still a slight performance regression for very giant pdf. But it is enough for most use case.
But the bottom line is "it's actually worth to do it because people are using it". They won't actively support a feature that little people use because they don't have the people to support it.
Huh? How would a static site generator serve both RSS and the HTML view of the RSS from the same file?
To be extra clear: I want to have <a href="feed.xml">My RSS Feed</a> link on my blog so everyone can find my feed. I also want users who don't know about RSS to see something other than a wall of plain-text XML.
You don't serve them from the same file. You serve them from separate files.
As I mention in my other comment to you, I don't know why you want an RSS file to be viewable. That's not an expected behavior. RSS is for aggregators to consume, not for viewing.
Technically, the web server can do content negotiation based on Accept headers with static files. But… In theory, you shouldn't need a direct link to the RSS feed on your web page. Most feed readers support a link-alternate in the HTML header:
Someone who wants to subscribe can just drop example.com/blog in to the feed reader and it will do the right thing. The "RSS Feed" interactive link then could go to a HTML web page with instructions for subscribing and/or a preview.
