Comment by LegionMammal978
3 months ago
Oh hey, that thing happened that one could easily see was going to happen [0]. The writing was on the wall for XSL as soon as the browsers tore out FTP support: their desire to minimize attack surface trumps any tendency to leave well enough alone.
I wonder what the next step of removing less-popular features will be. Probably the SMIL attributes in favor of CSS for SVG animations, they've been grumbling about those for a while. Or maybe they'll ultimately decide that they don't like native MathML support after all. Really, any functionality that doesn't fit in the mold of "a CSS attribute" or "a JS method" is at risk, including most things XML-related.
CSS animations still lack a semantic way to sequence animations based on the beginning/end of some other animation, which SMIL offers. With SMIL you can say 'when this animation ID begins/ends only then trigger this other animation', including time offsets from that point.
Which is miles better than having to having to use calcs for CSS animation timing which requires a kludge of CSS variables/etc to keep track of when something begins/ends time-wise, if wanting to avoid requiring Javascript. And some years ago Firefox IIRC didn't even support time-based calcs.
When Chromium announced the intent to deprecate SMIL a decade back (before relenting) it was far too early to consider that given CSS at that time lacked much of what SMIL allowed for (including motion along a path and SVG attribute value animations, which saw CSS support later). It also set off a chain of articles and never-again updated notes warning about SMIL, which just added to confusion. I remember even an LLM mistakenly believing SMIL was still deprecated in Chromium.
> if wanting to avoid requiring Javascript.
And there's one of the issues: browser devs are perfectly happy if user JS can be used to replicate some piece of functionality, since then it's not their problem.
> their desire to minimize attack surface trumps any tendency to leave well enough alone.
Is that a good thing or a bad thing?
Technical people like us have our desires. But the billions of people doing banking on their browsers probably have different priorities.
There's ways to reduce attack surface short of tearing out support. Such as, for instance, taking one of those alleged JS polyfills and plugging it into the browser, in place of all the C++. But if attack surface is your sole concern, then one of those options sounds much easier than the other, and also ever-so-slightly superior.
In any case, there's no limit on how far one can disregard compatibility in the name of security. Just look at the situation on Apple OSes, where developers are kept on a constant treadmill to update their programs to the latest APIs. I'd rather not have everything trend in that direction, even if it means keeping shims and polyfills that aren't totally necessary for modern users.
It is a balance (compatibility vs attach surfaces). The issue with XSLT (which I am still a strong advocate for) is that nobody is maintaining that code. So vulnerabilities sit there undetected. Like the relatively recent discovery of the xsl:document vulnerability.
6 replies →
> their desire to minimize attack surface trumps any tendency to leave well enough alone.
It's that why Chrome unilaterally releases 1000+ web APIs a year, many of them quite complex, and spanning a huge range of things to go wrong (including access to USB, serial devices etc.)? To reduce the attack surface?
Well, their desire to stay trendy trumps their desire to minimize attack surface, I'd have to imagine. Alas, XML is roughly the polar opposite of trendy, mostly seen as belonging in the trash heap of the 90s alongside SOAP, CORBA, DCOM, Java applets, etc.
> The writing was on the wall for XSL as soon as the browsers tore out FTP support
When did they do that? Can I not still ftp://example.com in the url bar?
FTP support was completely removed from Chrome with the release of Chrome 88, which was released in January 2021