> Cancelling XSLT is going in the wrong direction (IMHO).

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. The people doing the wailing/rending/gnashing about the removal of libxslt needed to step up to fix and maintain it.

It seems like something an extension ought to be capable of, and if not, fix the extension API so it can. In firefox I think it would be a full-blown plugin, which is a lower-level thing than an extension, but I don't know whether Chromium even has a concept of such a thing.

▲

dragonwriter 19 hours ago | parent | next [-]

> 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 19 hours ago | parent [-]

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

▲

dragonwriter 18 hours ago | parent | next [-]

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 18 hours ago | parent [-]

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

▲

dragonwriter 17 hours ago | parent [-]

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 17 hours ago | parent [-]

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 17 hours ago \| parent [-]
		> 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 18 hours ago | parent | prev [-]

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

	▲	tptacek 18 hours ago \| parent [-]
		I just don't understand it. I don't understand it well enough to call out what's questionable about it.

▲

Kwpolska 19 hours ago | parent | prev | next [-]

Or perhaps the multi-billion-dollar corporations could stop piggy-backing on volunteers and invest in maintaining the Web platform?

▲

mpyne 14 hours ago | parent | next [-]

They did, the issue is that the improved Web platform they invested so much to build and maintain has no use for XSLT, which is obsolete in the modern world of good JavaScript, JSON and modern Fetch APIs.

▲

robocat 17 hours ago | parent | prev [-]

Which popular browsers are significantly leaning on individual contributors or volunteers?

▲

Kwpolska 17 hours ago | parent | next [-]

Google decided to drop XSLT, because the volunteer-maintained libxslt had no maintainers for some time. So, instead of helping the project, they just decided to remove a feature.

	▲	aleph_minus_one 12 hours ago \| parent [-]
		But by (attempting to) remove this dependency, Google indeed decided to stop piggy-backing on another volunteer - as requested. Be careful what you wish for. :-)

▲

josefx 16 hours ago | parent | prev | next [-]

Were you born before or after heartbleed uncovered the sorry state of OpenSSL and the complete absence of funding it was maintained under?

So to answer your question: Every single one of them, from Google with its billions, to Mozilla with Googles billions, none of them would spend even a cent on critical open source projects they relied on as long as they could get away with it.

▲

mhitza 17 hours ago | parent | prev [-]

Almost all of them? as I recall there was a single volunteer developer maintaining the xml/xslt libraries they were using.

Wasn't it similar with openssl 13+ years ago? Few volunteer maintainers, and only after a couple of major vulnerabilities money got thrown at that project?

I'm sure there's more and that's why the famous xkcd comic is always of relevance.

▲

Fileformat 18 hours ago | parent | prev | next [-]

So... you want newbies to install an extension/plugin before they get a human-readable view of a feed???

That's about as new-user-hostile as I can imagine.

	▲	MrJohz 17 hours ago \| parent [-]
		There are plenty of ways around this. As others have pointed out, there are other options for styling XML that work well enough in practice. You can also do content negotiation on the server, so that a browser requesting an html document will get the human-readable version, while any feed reader will be sent the XML version. (If you render the html page with XSLT, you can even take advantage of better XSLT implementations where you don't need to work around bugs and cross-platform jank.) Or you can rely on `link` tags, letting users submit your homepage to their feed reader, and having the feed reader figure out where everything is. There might even be a mime code for RSS feeds, such that if you open an RSS feed in your browser, it automatically figures out the correct application (i.e. your preferred RSS reader) to open that feed in. But I've not seen that actually implemented anywhere, which is a shame, because that seems like by far the best option for user experience.

▲

imiric 18 hours ago | parent | prev [-]

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