-
Notifications
You must be signed in to change notification settings - Fork 140
Clarify role of EventListenerOptions in identifying handlers #5
Comments
This has implications on the shape of If two event handlers with distinct removeEventListener("scroll", handler) should remove handler no matter what I think it would probably be simplest to be consistent with |
Right, I wasn't even intending to question here whether addEventListener(type, handler, {requiresCancelable: true});
addEventListener(type, handler, {requiresCancelable: false}); As defined at the moment that always adds two. I wrote it this way for the reason you mention - consistency among all options (although I did have an earlier proposal that omitted this and, as you say, didn't need to extend The subtler question is how exactly does the default value of |
That sounds confusing to me. I think null should be considered distinct from I agree that unspecified should be the same as null. |
Issue #5 Also fixes a silly bug with the return values of add/removeEventListener.
What do you think of it now? There's technically a lot of changes necessary to the DOM spec to accommodate this, but I think this gets the point across now. |
This LGTM. |
It's not be entirely clear whether:
Adds one event listener or two. Similarly, what about:
The text was updated successfully, but these errors were encountered: