WICG / EventListenerOptions

An extension to the DOM event pattern to allow authors to disable support for preventDefault
Other
1.17k stars 140 forks source link

Clarify role of EventListenerOptions in identifying handlers #5

Closed RByers closed 9 years ago

RByers commented 9 years ago

It's not be entirely clear whether:

   addEventListener(type, handler);
   addEventListener(type, handler, {requiresCancelable: null});

Adds one event listener or two. Similarly, what about:

   addEventListener("scroll", handler, {requiresCancelable: false});
   addEventListener("scroll", handler, {requiresCancelable: null});
tdresser commented 9 years ago

This has implications on the shape of removeEventListener.

If two event handlers with distinct requiresCancelable values are considered the same, then no modification to removeEventListener is needed, and:

removeEventListener("scroll", handler)

should remove handler no matter what requiresCancelable is set to.

I think it would probably be simplest to be consistent with useCapture, and have your example add two event listeners. This preserves symmetry between addEventListener and removeEventListener, and consistency between the parameters to addEventListener.

RByers commented 9 years ago

Right, I wasn't even intending to question here whether requiresCancelable should participate in this, i.e. whether this should add one or two:

   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 removeEventListener).

The subtler question is how exactly does the default value of requiresCancelable fit into this? Is unspecified the same as null (I think it should be)? Is null considered the same as false (or true) when they have the same semantics? Maybe issue #7 will address this.

tdresser commented 9 years ago

Is null considered the same as false (or true) when they have the same semantics?

That sounds confusing to me. I think null should be considered distinct from true and false, even if they have the same semantics (assuming we do go with a boolean).

I agree that unspecified should be the same as null.

RByers commented 9 years ago

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.

tdresser commented 9 years ago

This LGTM.