> It's a dead format that no one uses[1],

This has to be proven by Google (and other browser vendors), not by people coming up with examples. The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples: https://github.com/whatwg/html/issues/11523#issuecomment-315...

Meanwhile Google's own document says that's not how you approach deprecation: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...

Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity... with USB https://chromestatus.com/metrics/feature/timeline/popularity... or WebTransport: https://chromestatus.com/metrics/feature/timeline/popularity... or even MIDI (also supported by Firerox) https://chromestatus.com/metrics/feature/timeline/popularity....

XSLT deprecation is a symptom of how browser vendors, and especially Google, couldn't give two shits about the stated purposes of the web.

To quote Rich Harris from the time when Google rushed to remove alert/confirm: "the needs of users and authors (i.e. developers) should be treated as higher priority than those of implementors (i.e. browser vendors), yet the higher priority constituencies are at the mercy of the lower priority ones" https://dev.to/richharris/stay-alert-d

▲

Aurornis 7 hours ago | parent | next [-]

> Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity... with …

Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages setting up a device. I wouldn’t expect it to show up on a large percentage of page loads.

XSLT was supposed to be a broad standard with applications beyond single setup pages. The fact that those two features are used similarly despite one supposedly being a broad standard and the other being a niche feature that only gets used in unique cases (device setup or debugging) is only supportive of deprecating XSLT, IMO

▲

kstrauser 7 hours ago | parent | next [-]

Furthermore, you can’t polyfill USB support. It’s something that the browser itself must support if it’s going to be used at all, as by definition it can’t run entirely inside the browser.

That’s not true for XSLT, except in the super-niche case of formatting RSS prettily via linking to XSLT like a stylesheet, and the intersection of “people who consume RSS” and “people who regularly consume it directly through the browser” has to be vanishingly small.

▲

troupo an hour ago | parent [-]

> Furthermore, you can’t polyfill USB support.

You can't polyfill many things. Should we just dump everything into the browser? Well, Google certainly thinks so. But that makes the question about "but this feature is unused, why support it" moot.

And Google has no intention to support a polyfill, or ship it with the browser. The same person who didn't even know that XSLT is used on podcast sites scribbled together some code, said "here, it's easy", and that's it.

And the main metric they use for deprecations is the number of sites/page uses. So even that doesn't work in favor of all the hardware APIs (and a few hundred others) that Google just shoved into the browser.

At least there's consensus on removing XSLT, right? But there are many, many objections about USB, HID, etc. And still that doesn't stop Google from developing, shipping and maintaining them.

Basically, the entire discussion around XSLT struck a nerve partly because all of the arguments can immediately be applied to any number of APIs that browsers, and especially Chrome, have no trouble shipping. And that comes on top of the mismanaged disaster that was the attempt to remove alert/confirm several years ago (also, "used on few sites", "security risk", "simpler code", "full browser consensus" etc.)

	▲	kstrauser 8 minutes ago \| parent [-]
		The distinction in my mind is that if a browser doesn’t ship with XSLT, then devs have to go through the hassle of adding support for it themselves, but if a browser doesn’t support a device driver, it’s completely impossible for devs to do that themselves. Without built-in support, XSLT is inconvenient. Without built-in support, things like WebUSB cannot possibly exist. That’s why I think they can’t be compared directly.

▲

troupo 7 hours ago | parent | prev [-]

> Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages

So, if XSLT sees 10x usage of USB we can consider it a "niche technology that is 10x useful tan USB"

> The fact that those two features are used similarly

You mean USB is used on 10x fewer pages than XSLT despite HN telling me every time that it is an absolutely essential technology for PWAs or something.

▲

coldpie 6 hours ago | parent | prev [-]

> This has to be proven by Google (and other browser vendors), not by people coming up with examples

What, to you, would constitute sufficient proof? Is it feasible to gather the evidence your suggestion would require?

	▲	troupo an hour ago \| parent [-]
		> What, to you, would constitute sufficient proof? Is it feasible to gather the evidence your suggestion would require? Let me quote from my comment, again: --- start quote --- The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples --- end quote --- I would like to see more evidence than "we couldn't care less, remove it" before a consensus on removal, before an "intent to deprecate" and before opening a PR to Chrome removing the feature. Funnily enough, even the "browser consensus" looks like this: "WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support": https://github.com/whatwg/html/issues/11523#issuecomment-314... BTW. Literally the only "evidence" originally presented was "nearly 100% of sites use JS, while 1/10000 of those use XSLT.": https://github.com/whatwg/html/issues/11523#issuecomment-315... which was immediately called into question: https://github.com/whatwg/html/issues/11523#issuecomment-315... and https://github.com/whatwg/html/issues/11523#issuecomment-315... and that's before we account for google's own docs saying they have a blind spot in the enterprise/corporate setting where people suspect the usage may be higher. Also, as I say. I think the main issue isn't XSLT itself. XSLT is a symptom.