This is useful because feed URLs look the same as web page URLs, so users are inclined to click on them and open them in a web browser instead of an RSS reader. (Many users these days don't even know what an RSS reader is). The stylesheet allows them to view the feed in the browser, instead of just being shown the XML source code.
Why is this so critical? We dont due this for any other format. If you put an ms office document on a page, we dont have the browser render it, we download it and pass it off to a dedicated program. Why is RSS so special here?
Because we want RSS to be friendly to new users. If you display a RSS feed as a wall of XML text, no new user will understand. If you just make it so clicking a RSS link brings up a blurb about RSS is & links on how to use, they might understand.
And we have done it for other formats: PDF is now quite well supported in browsers without plugins/etc.
An RSS feed is not a document meant for viewing. It's not like PDF or HTML or a video.
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.
People learn what to do with RSS the same as with anything else. They look it up or someone tells them. It's not like a .psd file tells you what it is, if you don't have Photoshop installed.
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.
"Semantic" means making all distinctions you care about and not making any distinctions you do not care about. This means a custom notation for nearly every case. XML is such a tool. And XSLT is a key component to make all these notations compatible with each other.
That is not what "semantic web" means. Semantic web was a series of standards (rdf and friends) made by w3c from the early 2000s that didnt really catch on.
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.
Ok but maintaining a web browser that supports a ton of small features that nobody-except-me-and-my-cousin are using has a huge cost; you don’t support obscure features just because someone somewhere is relying on it (relevant: https://xkcd.com/1172/).
Why would Google keep supporting AMP if the line is drawn only by use?
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.
Well, IMO it would be cool if we could do that, but the MS Office formats are a lot more complicated so it's a lot more work to implement. Also, quite often the whole point of sharing a file in MS Office format is so that the user can take it and edit it, which would require a dedicated program anyway.
If you think about it, basically nothing except HTML is a critical function of browsers. You can solve everything just with that. We don’t even need CSS, or any custom styling at all. JavaScript is absolutely not necessary.
> font, color, and others are no longer in HTML5 spec.
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'
I don't think it's a critical feature, but it is nice-to-have.
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.
Yeah, but browsers actually make use of that format. And its not like you can add a special header to jpg files to do custom reformatting of the jpeg via a turing complete language. Browsers just display the file.
You can do the transformation server-side, but it's not trivial to set it up. It would involve detecting the web browser using the "Accept" header (hopefully RSS readers don't accept text/html), then using XSLT to transform the XML to XHTML that is sent to the client instead, and you probably need to cache that for performance reasons. And that's assuming the feed is just a static file, and not dynamically generated.
In theory you could do the transformation client side, but then you'd still need the server to return a different document in the browser, even if it's just a stub for the client-side code, because XML files cannot execute Javascript on their own.
Another option is to install a browser extension but of course the majority of users will never do that, which minimizes the incentive for feed authors to include a stylesheet in the first place.
How about using Javascript to fetch the XML (like you would do with JSON), and then parse/transform it with a Javascript or wasm XSLT library? Just like you would do with JSON.
You need a server to serve Json as well. Basically, see XML as data format.
RSS readers are not chrome, so they have their own libraries for parsing/transforming with XSLT.
Not without servers rendering the HTML or depending on client-side JS for parsing and rendering the content.
Its also worth noting that the latest XSLT spec actually supports JSON as well. Had browsers decided to implement that spec rather than remove support all together you'd be able to render JSON content to HTML entirely client-side without JS.
Random example: https://lepture.com/en/feed.xml
This is useful because feed URLs look the same as web page URLs, so users are inclined to click on them and open them in a web browser instead of an RSS reader. (Many users these days don't even know what an RSS reader is). The stylesheet allows them to view the feed in the browser, instead of just being shown the XML source code.