[dragonwriter]

> 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.

[tptacek]

Your argument here includes that browsers should retain native XSLT implementations because non-browsers have bad XSLT implementations?

[dragonwriter]

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.

[tptacek]

Is the idea that if they did so, the insecure non-browser XSLT-users could adopt their implementation?

[dragonwriter]

The idea is that if they did so, the people using software running in the browser could continue to use XSLT with just the browser platform because the functionality would still be there with a different backend implementation, but instead that in-browser XSLT functionality is going somewhere, specifically, away.

[tptacek]

Right but either way, the vulnerability exists today, and you're saying that whether or not the browser platform supports the functionality that harbors the vulnerabilities, the browser platform should be responsible for resolving those vulnerabilities. That's how I read it.

[dragonwriter]

> and you're saying that whether or not the browser platform supports the functionality that harbors the vulnerabilities, the browser platform should be responsible for resolving those vulnerabilities.

No, I'm not (and I keep saying this explicitly) saying that browsers should or should not do anything, or be responsible for anything. I’m not making a normative argument, at all.

I am stating, descriptively, that browser vendors choosing to remove XSLT functionality rather than repairing it by using an alternative implementation is very directly contrary to the claim made upthread that “XSLT isn’t going anywhere”. It is being removed from the the most popular application platform in existence, with developers being required to bring their own implementation for what was previously functionality supported by the platform. I am not saying that this is good or bad or that anyone should or should not do anything differently or making any argument about where responsibility for anything related to this lies.

[AlecSchueler]

What do you find questionable about this being included as part of the broader argument?

[tptacek]

I just don't understand it. I don't understand it well enough to call out what's questionable about it.