And we have done it for other formats: PDF is now quite well supported in browsers without plugins/etc.
It's a format intended for be consumed like an API call. It's like JSON. The link is something you import into an aggregator.
RSS feeds shouldn't even be displayed as XML at all. They should just be download links that open in an aggregator application. The same way .torrent files are imported into a torrenting client, not viewed.
1. This is pretty difficult for someone who doesn't know about RSS. How would they ever learn what to do with it?
2. Browsers don't do that. There used to be an icon in the URL bar when they detected an RSS feed. It would be wonderful if browsers did support doing exactly what you suggest. I'm not holding my breath.
I'm not looking to replicate my blog via XSLT of the RSS feed: that's what the blog's HTML pages are. I just don't want to alienate non-RSS users.
I don't think you need to worry about "alienating" non-RSS users. If somebody clicks on an RSS link without knowing what RSS is and sees gibberish, that's not really on you. They can just look it up. Or if you want, you can put a little question-mark icon next to the RSS link if you want to educate people. But mostly, for feeds and social media links, people just ignore the icons/acronyms they don't recognize.
And: Because it exists/existed and thus people relied upon it.
With the amount of sites on the web, even a small number relying on features, each having just a bunch of users, it becomes a big number of impacted.
And XSLT in that context is interesting as one can ship the RSS file, the web browser renders it with XSLT to human readable and a smart browser can do smart things with it. All from the same file.
They chose to kill off a spec and have it removed from every browser because they don't like it. They choose to keep maintaining AMP because its their pet project and spec. Its as simple as that, it has nothing to do with limited resources forcing them to trim features rather than maintain or improve them.
You can have a document without CSS but you can’t style it.
You can have a document without JavaScript but only a static one (still interactive, but only though forms)
On the other hand, you can replace XSLT with server side rendering, or JavaScript. It does not serve a truly unique function.
What? CSS didn't come around until several years after HTML did. And you can certainly style an HTML document without CSS.
> On the other hand, you can replace XSLT with server side rendering, or JavaScript.
You can also execute JavaScript on the server to make browsers more secure, but I don't see browser makers clamoring to remove JavaScript support.
> It does not serve a truly unique function.
It does, though. It lets someone do some basic programming of some web pages without having to become a developer
> You can also execute JavaScript on the server to make browsers more secure, but I don't see browser makers clamoring to remove JavaScript support.
JS is not there just for client side static DOM rendering. Something like Google Maps or an IRC chat would be a much poorer experience without it.
Sometimes browsers are asked to render HTML documents that were written decades ago to conform to older specs and are still on the internet. That still works
> JS is not there just for client side static DOM rendering. Something like Google Maps or an IRC chat would be a much poorer experience without it.
Of course they would. That's most of the point. You can do a lot more damage with JavaScript than you currently can with XSLT, but XSLT has to go because of 'security concerns'
Imagine if you opened a direct link to a JPEG image and instead of the browser rendering it, you'd have to save it and open it in Photoshop locally. Wouldn't that be inconvenient?
Many browsers do support opening web-adjacent documents directly because it's convenient for users. Maybe not Microsoft Word documents, but PDF files are commonly supported.