forked from WebAudio/web-audio-api
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Link event handlers IDL attributes to event types
Changes in WebAudio#2498 introduce a weird phrasing for "fire an event", e.g. "Fire an event to onstatechange EventHandler". Correct phrasing should rather be "Fire an event named statechange". This made me realize that the spec never associates the event handler IDL attributes that it defines with the actual event handler event type that gets fired. The spec also seems to assume that there will be at most one event handler (e.g. when it says that "This AudioBuffer is only valid while in the scope of the onaudioprocess function"), whereas `onxxx` is just one way to listen to `xxx` events, `addEventListener` may also be used. Specs typically make the association between event handler IDL attributes and event handler event types explicit, e.g. as done in HTML through tables such as: https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects ... or in WebRTC through text in the definition of the IDL attribute: https://w3c.github.io/webrtc-pc/#ref-for-event-datachannel-bufferedamountlow-1 This pull request adds definitions of event types next to the definitions of the `onxxx` IDL attributes with which they are associated and uses references to these event types whenever the spec fires an event or mentions event handlers. I tried to keep the changes minimal. I was going to argue that these changes are editorial in nature as they merely clarify something that did not create ambiguities for implementations. Now, you seem to track all changes with "proposed corrections", regardless of whether they're editorial or substantive so I suspect you cannot accept these changes as-is... At a minimum, I think that the occurrences of "fire an event to onxxx" should be fixed (they only appear in proposed corrections so that seems doable without creating additional proposed corrections). I can prepare a separate PR to that effect. I can also look into creating appropriate "proposed corrections" structures for the other changes if they seem useful. That may not be worth the hassle.
- Loading branch information
Showing
1 changed file
with
52 additions
and
56 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters