MIDI device enumeration is behind a permissions prompt, though? "The user must explicitly grant permission to use the API though a user-agent specific mechanism, or have previously granted permission." https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
> But maybe it doesn't look as slow from the outside?
Google ships 400 new APIs per year. It readily ships API within a month after it spits out a half-prepared spec and asks other browsers for input.
Even benign changes like CSS headline balancing was sent to TAG three weeks ago, and will ship a month from now.
From the outside this is neck-breaking speed with utter disregard for anything. But when user privacy is concerned? Nah, must spend sweet time to do anything.
Isn’t that the point of the RFC approach to standardization? “Here’s what we think should be done, with the PoC being what we’re already doing ourselves in production; feel free to try our impl out, in order to better notice the design flaws in practice, so that we can talk out what changes could be made before it becomes a de-facto standard we’re all stuck with”? SPDY → HTTP2 was a great example of Google doing exactly this.
The opposite of the RFC approach is the “airy design document written by standards body in reference to nothing, never implemented by anyone” approach; and I know which of the two I prefer.
> Here’s what we think should be done, with the PoC being what we’re already doing ourselves in production
The problem with having anything in "production" on the web is that you can neither update it or change it because people will rely on it.
The idea behind web standards is that there should be at least two independent implementations, tested behind a flag, with iterations on design, before it becomes a full standard.
Chrome's approach for the past several years has been: spit out a half-completed spec, "ask" other browser for input.... and ship it in prod a month later.
EDIT: nope, not as implemented in Chrome https://www.jefftk.com/test/webmidi