Event Handlers vs. Event Listener and implicit call to `open()`
padenot opened this issue · 4 comments
The spec currently states the following (emphasis mine):
Note that this call is NOT required in order to use the MIDIPort- calling send() on a MIDIOutput or attaching a MIDIMessageEvent handler on a MIDIInput will cause an implicit open().
This means that, if output
is a MIDIOutput
object, the following snippet (setting an event handler) opens the port:
output.onmidimessage = (m) => { console.log(m); }
but the following (adding an event listener) doesn't:
output.addEventListener("midimessage", () => { console.log(m); });
It seems like we need to state that both ways open the port, for Web Compat reasons.
https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers
https://dom.spec.whatwg.org/#concept-event-listener
Without knowing this for sure I would imagine the distinction between setting an event handler and adding an event handler is made on purpose.
The description of MIDIOutput.open()
is surprisingly close to the one for MessagePort.start()
. Calling start()
on a MessagePort
is also not necessary when using onmessage
. But it's necessary when adding an event handler with addEventListener()
.
Yes, but this is not what has been shipped for as long as Web MIDI has been shipped, and not doing it breaks lots of websites ("for Web Compat reasons").
Sorry, I misunderstood the issue. Because of the links I thought you meant onevent
and addEventListener('event', ...)
should generally do the same thing.
I didn't even know that start()
gets called automatically in Chrome when using addEventListener()
. I always did it manually. :-)
Audio Working Group 2023-10-05 meeting conclusions:
- We should add the requirement for addEventListener as well
- If possible, copy language directly from the spec links in the first comment on this issue