Comment by dragonwriter
6 hours ago
> XSLT isn't going anywhere: hardwiring into the browser an implementation that's known to be insecure and is basically unmaintained is what's going away.
Not having it available from the browser really reduces the ability to use it in many cases, and lots of the nonbrowser XSLT ecosystem relies on the same insecure, unmaintained implementation. There is at least one major alternative (Saxon), and if browser support was switching backing implementation rather than just ending support, “XSLT isn’t going anywhere” would be a more natural conclusion, but that’s not, for whatever reason, the case.
Your argument here includes that browsers should retain native XSLT implementations because non-browsers have bad XSLT implementations?
I don’t see anything that looks remotely like a normative argument about what browsers should or should not do anywhere in my post that you are responding to, did you perhaps mean to respond to some other post?
My point was that the decision to remove XSLT support from browsers rather than replacing the insecure, unmaintained implementation with a secure, maintained implementation is an indicator opposed to the claim "XSLT isn’t going anywhere”. I am not arguing anything at all about what browser vendors should do.
Is the idea that if they did so, the insecure non-browser XSLT-users could adopt their implementation?
3 replies →
What do you find questionable about this being included as part of the broader argument?
I just don't understand it. I don't understand it well enough to call out what's questionable about it.