That said, I never used XSLT for anything, and I don’t see how is its support in browsers tied to RSS. (Sure you could render your page from your rss feed but that seems like a marginal use case to me)
This really is just a storm in a waterglass. Nothing like the hundreds or tens of thousands of flash and java applet based web pages that went defunct when we deprecated those technologies.
Again: this is nothing like Flash or Java applets (or even ActiveX). People were seriously considering Apple's decision to not support Flash on iPhone as a strategic blunder due to the number of sites using it. Your local news station probably had video or a stock market ticker using Flash. You didn't have to hunt for examples.
I've spent the last several years making a website based on XML and XSLT. I complain about the XML/XSLT deprecation from browsers all the time. And the announcements in August that Google was exploring getting rid of XSLT in the browser (which, it turned out, wasn't exploratory at all, it was a performative action that led to a foregone conclusion) was so full of blowback that the discussion got locked and Google forged ahead anyway.
> Is it possible that installing an XSLT processor on the server is not as big a hassle as everyone pretends?
This presumes that everyone interested in making something with XML and XSLT has access to configure the web server it's hosted on. With support in the browser, I can throw some static files up just about anywhere and it'll Just Work(tm)
I don't have any desire to learn JavaScript (or use someone else's script) just to do some basic templating.
XML Parsing Error: mismatched tag. Expected: </item>.
Location: https://example.org/rss.xml
Line Number 71, Column 3:
</channel>
--^
I enabled the nginx XSLT module on a local web server serve the files to myself that way. Now when it fails I can check the logs to see what instruction it failed on. It's a bad experience, and I'm not arguing otherwise, but it's just about the only workaround left.
It's a circular situation: nobody wants to use XSLT because the tools are bad and nobody wants to make better tools because XSLT usage is too low.
Sure, but Flash and Java were never standards-compliant parts of the web platform. As far as I'm aware, this is the first time that something has been removed from the web platform without any replacements—Mutation Events [0] come close, but Mutation Observers are a fairly close replacement, and it took 10 years for them to be fully deprecated and removed from browsers.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/MutationEve...
Up until a few years ago, I could debug basic stuff in FireFox. If Firefox encountered an XSLT parsing error, it would show an error page with a big ASCII arrow pointing to the instruction that failed. That was a useful clue. Now it shows a blank page, which is not useful at all.
Although I don't have firm evidence, haven't worked at Google, and you likely know company dynamics better than I.
In the golden old days of 2018, browsers at least applied some styling https://evertpot.com/firefox-rss/
You can still manually apply styling using xslt https://www.cedricbonhomme.org/blog/index.xml
Unless I'm using XSLT without knowing, you can do this with the xml-stylesheet processing instruction
Link: </style.css>; rel=stylesheet
I think the best strategy for Google is to support this and simultaneously ditch XSLT. This way nothing is truly lost.
[1] You can test your browser from: https://annevankesteren.nl/test/html-element/style-header.ph...
XSLT does much more than CSS.
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.
Or can't you polyfill this / use a library to parse this?
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.
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.
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.
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.
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'
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.
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.