Another way to look at this is:
Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?
Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?
Applied to each individually it seems to make sense. However the aggregate effect is kill off a substantial portion of the web.
In fact, it's an argument to never add a new web technology: Should 100% of web users be made vulnerable to bugs in a new technology that 0% of the people are currently using?
Plus it's a false dichotomy. They could instead address XSLT security... e.g., as various people have suggested, by building in the XSLT polyfill they are suggesting all the XSLT pages start using as an alternative.
Ps. The XSLT language is actively maintained and is used in many applications and contexts outside of the browser.
If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are trying to have the browser replace the whole OS.
For now, there's no alternative that allows serving an XML file with the raw data from e.g. an embedded microcontroller in a way that renders a full website in the browser if desired.
Even more so if you want to support people downloading the data and viewing it from a local file.
Your microcontroller only serves the actual xml data, the xslt is served from a different server somewhere else (e.g., the manufacturer's website). You can download the .xml, double-click it, and it'll get the xslt treatment just the same.
In your example, either the microcontroller would have to serve the entire UI to parse and present the data, or you'd have to navigate to the manufacturers website, input the URL of your microcontroller, and it'd have to do a cors fetch to process the data.
One option I'd suggest is instead of
<?xml-stylesheet href="http://example.org/example2.xsl" type="text/xsl" ?>
<?xml-stylesheet href="http://example.org/example2.js" type="application/javascript" ?>
The service worker would not be associated with any specific origin, but it would still receive the regular lifecycle of events, including a fetch event for every load of an xml document pointing at this specific service worker script.
Using https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/... it could respond to the XML being loaded with a transformed response, allowing it to process the XML similar to an XSLT.
You could even have a polyfill service worker that loads an XSLT and applies it to the XML.
I don't think anyone is arguing that XSLT has to be fast.
You could probably compile libxslt to wasm, run it when loading xml with xslt, and be done.
Does XSLT affect the DOM after processing, isn't it just a dumb preprocessing step, where the render xhtml is what becomes the DOM.
The first strategy is obviously correct, but Google wants strategy 2.
So site operators who rely on this feature today are not merely asked to load a polyfill but to fundamentally change the structure of their website - without necessarily getting to the same result in the end.