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

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.