Comment by MrJohz
3 months ago
Sure, but this requires someone sitting down and writing the JS polyfill, and then maintaining it indefinitely. And for something as complicated as XSLT, that will surely be indefinite maintenance, because complicated specs beget complicated implementations.
In the absence of anyone raring to do that, removal seems the more sensible option.
The vendor discussion on removing XSLT is predicated on someone creating a polyfill for users to move to. It is not an unreasonable assumption because a polyfill can be created fairly trivially by compiling the existing XSLT processor to WASM.
And it is also fairly trivial to put that polyfill into the browsers.
The Chrome team has been moaning about XSLT for a decade. If security was really their concern they could have replaced the implementation with asm.js a decade ago, just as they did for pdfs.
> Sure, but this requires [...] maintaining it indefinitely.
Does it, though? Browsers already have existing XSLT stacks, which have somehow gotten by practically unmodified for the last 20 years. The basic XSLT 1.0 functionality never changes, and the links between the XSLT code and the rest of the codebase rarely change, so I find it hard to believe that slapping it into a sandbox would suddenly turn it into a persistent time sink.
Wasn't this whole discussion sparked by a fairly significant bug in the libxslt implementation? There's also a comment from a Chrome developer somewhere in this thread talking about regularly trying to fix things in libxslt, and how difficult that was because of how the library is structured.
So it is currently a persistent time sync, and rewriting it so that it can sit inside the browser sandbox will probably add a significant amount of work in its own right. If that's work that nobody wants to do, then it's difficult to see what your solution actually is.
The current problem is that bugs in libxslt can have big security implications, so putting it or an equivalent XSLT 1.0 processor in a safe sandbox would make active maintenance far less urgent, since the worst-case scenario would just be presentation issues.
As for immediate work, some in this thread have proposed compiling libxslt to WASM and using that, which sounds perfectly viable to me, if inefficient. WASM toolchains have progressed far enough that very few changes are needed to a C/C++ codebase to get it to compile and run properly, so all that's left is to set up the entry points.
(And if there really were no one-for-one replacement short of a massive labor effort, then current XSLT users would be left with no simple alternative at all, which would make this decision all the worse.)