If there were that many, why do people only list the same handful again and again? And where are all the /operators/ of those websites complaining? Is it possible that installing an XSLT processor on the server is not as big a hassle as everyone pretends?
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.
> If there were that many, why do people only list the same handful again and again? And where are all the /operators/ of those websites complaining?
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)
Running a script that interprets a different script to transform a document just complicates things. What do I do when the transform fails? I have to figure out how to debug both XSLT and JavaScript to figure out what broke.
I don't have any desire to learn JavaScript (or use someone else's script) just to do some basic templating.
What does one do when transform fails right now? You have to debug both XSLT and a binary you don't have the source for; debugging JavaScript seems like a step up, right?
I used to be able to load the local XML and XSLT files in a browser and try it. When the XSLT blew up, I'd get a big ASCII arrow pointing to the part that went 'bang'. It still only kind of works in FireFox
XML Parsing Error: mismatched tag. Expected: </item>.
Location: https://example.org/rss.xml
Line Number 71, Column 3:
</channel>
--^
Chrome shows a useless white void.
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.
