Has this proposal stalled?

[7ombie]

I was really excited about this proposal, and repeatedly end up back at this repo, hoping some progress has been made with it. Even if it was only in Chrome for the foreseeable, at least we could begin to create low-latency apps with web technology. At the moment, WebMIDI is almost pointless, and stuff like WebGL and WebAudio are undermined by the fact that user input always has highly variable latency in the browser.

Is there any hope of this shipping within the next couple of years?

[7ombie]

This proposal has obviously been abandoned.

Threaded MIDI

The people behind the WebMIDI API have now accepted the need for threaded MIDI, so that's moving forwards now.

To be fair, MIDI should've always been beyond the scope of this proposal, as keyboard and pointer events are heavily tied to the DOM, while MIDI events are always global (like Gamepad, USB, BlueTooth etc events).

In any case, audio applications should be able to directly communicate with MIDI devices in workers (and audio worklets) in the future, optimistically, within a year or two.

Threaded Keyboard & Pointer Events

While threaded MIDI will be awesome, the Web still needs threaded keyboard and pointer events.

Technically speaking, we don't currently have a keyboard or pointer API on the Web. We have keyboard and pointer events (keydown, keyup etc), which are part of the DOM API and its event-machinery (bubbling, preventDefault, addEventListener etc).

I think we should accept the nature of the DOM API (along with its keyboard and pointer stuff), acknowledging that it is inextricably tied to the main thread, but also aim for a complete suite of APIs for global input, which includes the Gamepad API, WebMIDI, WebUSB, WebHID, WebBlueTooth etc, but also includes a new Keyboard API and Pointer API.

As global input events are completely unrelated to the DOM, their respective APIs should all be available in workers (and any appropriate worklets).

It would be nice if we could bind handlers to specific keyboard events (like when Space is pressed, or when Control + Tab is entered), instead of the very general events we have now (on keydown etc).

I don't have a thought-out proposal, but we do need to start working towards a new proposal for threaded keyboard and pointer events.

Exposing the DOM-related stuff to workers is probably impossible to do efficiently, but exposing APIs that only handle global input is realistic (and useful). Ideally, these new APIs would also have utility on the main thread, at least for apps that handle keyboard or pointer input globally.

Please discuss...

[7ombie]

It would be worth studying relevant JavaScript libraries to see what the community have come up with for keybinding, gestures etc, as we'll eventually need complete APIs for these things.

Note: Safari has a GestureEvent object.

[NavidZ]

cc @flackr @mustaqahmed

[marcoscaceres]

As the proposal has stalled, we will probably begin the process of archiving this repo.