Skip to content
This repository has been archived by the owner on Mar 19, 2018. It is now read-only.

Clarify role of EventListenerOptions in identifying handlers #5

Closed
RByers opened this issue Jul 3, 2015 · 5 comments
Closed

Clarify role of EventListenerOptions in identifying handlers #5

RByers opened this issue Jul 3, 2015 · 5 comments
Labels

Comments

@RByers
Copy link
Member

RByers commented Jul 3, 2015

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});
@RByers RByers added the spec label Jul 3, 2015
@tdresser
Copy link
Collaborator

tdresser commented Jul 3, 2015

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
Copy link
Member Author

RByers commented Jul 3, 2015

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
Copy link
Collaborator

tdresser commented Jul 3, 2015

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 added a commit that referenced this issue Jul 3, 2015
Issue #5

Also fixes a silly bug with the return values of add/removeEventListener.
@RByers
Copy link
Member Author

RByers commented Jul 3, 2015

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
Copy link
Collaborator

tdresser commented Jul 3, 2015

This LGTM.

@RByers RByers closed this as completed Jul 6, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants