RSS

Posted Aug 27, 2025 18:41 UTC (Wed) by josh (subscriber, #17465)
Parent article: The tangled web of XSLT browser support

> Aram Zucker-Scharff, said that getting rid of the capability to visually render RSS feeds would mean ""signing a death warrant for RSS feeds as an open technology"".

That makes no sense. The point of RSS is to read it in a feed reader, not a browser. If someone is looking directly at an RSS feed, it's probably not intentionally because they want to read the content. For most people I'd expect it to be a net improvement to render a direct RSS link as "This is an RSS feed, the title is XYZ, here's a set of feed readers you could read it in". *That* would bolster RSS adoption.

RSS

Posted Aug 27, 2025 19:22 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

I don't understand either

I do not understand the overall issue, to be honest

If someone wants to format xml in all kinds of way and cannot/will not do that server side, plugins are a thing; Some exist to modify json and xml in prettier format, so this seems like a sane way to resolve the situation

RSS

Posted Aug 27, 2025 20:05 UTC (Wed) by josh (subscriber, #17465) [Link]

I can understand the overall concern: this has been supported by web browsers for a very long time, and it breaks backward compatibility to take it away. That doesn't mean that it can't be, but it is important to replace the use cases (in a fashion that works for the current users, not just what people might hope the current users will switch to).

So, for instance, rendering helpful text for RSS feeds rather than raw XML, without requiring sites to do something different like server-side rendering, when they might not have any ability to run server-side anything.

RSS

Posted Aug 27, 2025 19:41 UTC (Wed) by jzb (editor, #7867) [Link] (5 responses)

If someone is looking directly at an RSS feed, it's probably not intentionally because they want to read the content.

Right, that's kind of his point. Web browsers don't natively handle RSS feeds anymore, so if a site includes a button for their regular RSS feed (rather than a link to Spotify or Apple Podcasts, or Feedly for regular RSS) and the user clicks it they just get the raw XML. Or, currently in Firefox, raw XML with the "This XML file does not appear to have any style information associated with it. The document tree is shown below." message which is not particularly friendly for most users.

With XSLT a site can provide something like this for an RSS feed: https://www.bennadel.com/rss, or this, which helpfully includes a little box at the top that explains what an RSS feed is and a link on how to use them. That's basically what you're describing to provide a "here's a set of feed readers" etc.

I may be wrong, but I don't think it will easily be possible for people who run WordPress or other blogging software on shared hosting to do server-side XSLT processing. That's a lot of feeds that won't be shown correctly if client-side XSLT processing goes away. (As an aside, that's a lot of feeds that aren't even discoverable if the site owner doesn't provide an RSS link, and/or the user doesn't have an extension that discovers RSS feeds for their browser... I use the Want My RSS extension to discover feeds in Firefox...)

RSS

Posted Aug 27, 2025 20:03 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

That's exactly what I'm suggesting that modern browsers should build in: recognize the RSS format and print a helpful message at the top, rather than just rendering it raw.

RSS

Posted Aug 27, 2025 20:18 UTC (Wed) by jzb (editor, #7867) [Link] (1 responses)

That would be great - but they've all explicitly moved away from supporting RSS, so I'm not holding my breath that they'd re-implement any RSS support to phase out XSLT. Perhaps I'm being too pessimistic, though... It's never happened before, but maybe this time...

RSS

Posted Aug 28, 2025 15:44 UTC (Thu) by iabervon (subscriber, #722) [Link]

I'd be happier if they moved to not trying to render RSS content either specially or as arbitrary XML, and defaulted to something that states that it's RSS and gives the URL in a way that's easy to copy into a program that does handle RSS. I always found it annoying that some sites had a link to a page that had the URL for the feed in it that I could look at and copy, and some had a link to the feed, and if I clicked on the link to the feed, the browser would act as a poor RSS reader that doesn't have my history and isn't integrated with my other feeds and also doesn't make the URL to copy easy to get.

RSS

Posted Aug 27, 2025 20:47 UTC (Wed) by archaic (subscriber, #111970) [Link]

I'm not convinced it was ever a good idea for web browsers to handle _any_ content that came over their sockets in a pretty human-readable away. I support the removal of xslt and even rss processing in a browser, but not the removal of xslt as a stylesheet format. If we were talking about a purely API-based middleware between a browser and a "unified" backend (possibly like libxslt) then technically it is no longer the browser doing any heavy lifting, is it? But then, I also don't want a browser to be opening any executable that might hand arbitrary data to arbitrary backends, either. Perhaps, as the protocol name expressly states, only HTTP data should be supported by a browser? ¯\_(ツ)_/¯

> https://www.bennadel.com/rss

Looks perfectly readable in raw curl output. Should curl make it prettier? I do not think so. The right app for the job. Browsers are not the right app for most jobs, though you wouldn't know that looking at all the jobs put on them.

RSS

Posted Aug 27, 2025 23:42 UTC (Wed) by jkingweb (subscriber, #113039) [Link]

> Web browsers don't natively handle RSS feeds anymore, so if a site includes a button for their regular RSS feed (rather than a link to Spotify or Apple Podcasts, or Feedly for regular RSS) and the user clicks it they just get the raw XML.

Not that you aren't correct in general, but Vivaldi does have an integrated feed reader, and you can subscribe to a feed using a button on the feed's readable representation (I assume this is achieved with XSLT, but I haven't checked).