Comment by imiric

> XSLT isn't going anywhere

XSLT as a feature is being removed from web browsers, which is pretty significant. Sure it can still be used in standalone tools and libraries, but having it in web browsers enabled a lot of functionality people have been relying on since the dawn of the web.

> hardwiring into the browser an implementation that's known to be insecure and is basically unmaintained is what's going away

So why not switch to a better maintained and more secure implementation? Firefox uses TransforMiix, which I haven't seen mentioned in any of Google's posts on the topic. I can't comment on whether it's an improvement, but it's certainly an option.

> The people doing the wailing/rending/gnashing about the removal of libxslt needed to step up to fix and maintain it.

Really? How about a trillion dollar corporation steps up to sponsor the lone maintainer who has been doing a thankless job for decades? Or directly takes over maintenance?

They certainly have enough resources to maintain a core web library and fix all the security issues if they wanted to. The fact they're deciding to remove the feature instead is a sign that they simply don't.

And I don't buy the excuse that XSLT is a niche feature. Their HTML bastardization AMP probably has even less users, and they're happily maintaining that abomination.

> It seems like something an extension ought to be capable of

I seriously doubt an extension implemented with the restricted MV3 API could do everything XSLT was used for.

> and if not, fix the extension API so it can.

Who? Try proposing a new extension API to a platform controlled by mega-corporations, and see how that goes.