New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EventListenerOptions and passive event listeners #82

Closed
wants to merge 1 commit into
base: master
from

Conversation

2 participants
@RByers
Contributor

RByers commented Sep 22, 2015

My first crack at incorporating the ideas and discussion from my EventListenerOptions proposal into the spec. The result can be previewed here.

One thing I'm still not super happy with is the somewhat confusing defaults for mayCancel. On the one hand we agreed that we wanted the performance behavior (mayCancel:false) the be the default when using the new API form. But we of course can't change the existing behavior. Let's discuss that further here if desired.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 22, 2015

Member

How does this address e.g., WICG/EventListenerOptions#20? Also, it's very confusing to still have outstanding discussion elsewhere. Not really sure what to pay attention to now.

Member

annevk commented Sep 22, 2015

How does this address e.g., WICG/EventListenerOptions#20? Also, it's very confusing to still have outstanding discussion elsewhere. Not really sure what to pay attention to now.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 22, 2015

Member

Basically, the way this is written I don't see much room for optimizations, unless you're doing something that's not allowed.

Member

annevk commented Sep 22, 2015

Basically, the way this is written I don't see much room for optimizations, unless you're doing something that's not allowed.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Sep 22, 2015

Contributor

It's addressed by what @smaug--- said. I.e. whether or not a particular event is cancelable is not the purview of DOM, it's up to the individual specs. So a handler being added 'too late' is the same as other scenarios where a non-cancelable event is received by a handler, so already covered by the DOM spec. If we can get consensus here, then I'll add something to touch-events (w3c/touch-events/#6) that indicates that a TouchEvent may be uncancelable if, at the time it was first received, there are no mayCancel=true handlers for it. WDYT? Is there something more I should add here (perhaps expand on the note?).

Regarding discussion, I thought there were enough separate non-trivial issues (with non-trivial discussion history) that it was valuable to continue to use a separate issue tracker for them. But if you prefer I can try to close them all and merge all discussion into this PR. I don't have a preference on whether minor editorial discussion occurs here or in separate issues. But I defer to you on all of this - what's easiest for you at this stage?

Contributor

RByers commented Sep 22, 2015

It's addressed by what @smaug--- said. I.e. whether or not a particular event is cancelable is not the purview of DOM, it's up to the individual specs. So a handler being added 'too late' is the same as other scenarios where a non-cancelable event is received by a handler, so already covered by the DOM spec. If we can get consensus here, then I'll add something to touch-events (w3c/touch-events/#6) that indicates that a TouchEvent may be uncancelable if, at the time it was first received, there are no mayCancel=true handlers for it. WDYT? Is there something more I should add here (perhaps expand on the note?).

Regarding discussion, I thought there were enough separate non-trivial issues (with non-trivial discussion history) that it was valuable to continue to use a separate issue tracker for them. But if you prefer I can try to close them all and merge all discussion into this PR. I don't have a preference on whether minor editorial discussion occurs here or in separate issues. But I defer to you on all of this - what's easiest for you at this stage?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 23, 2015

Member

Well, what I said in WICG/EventListenerOptions#20 (comment) is that what touch events do today doesn't require any changes in DOM. What you are suggesting here is that they observe listeners, which is something we want to avoid.

I don't really care where we settle on the design, but I'd like to settle on the design first. (I asked for the processing model before because the design wasn't clear. Now the processing model is clear, but the design seems wrong.)

Member

annevk commented Sep 23, 2015

Well, what I said in WICG/EventListenerOptions#20 (comment) is that what touch events do today doesn't require any changes in DOM. What you are suggesting here is that they observe listeners, which is something we want to avoid.

I don't really care where we settle on the design, but I'd like to settle on the design first. (I asked for the processing model before because the design wasn't clear. Now the processing model is clear, but the design seems wrong.)

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Sep 23, 2015

Contributor

Ok, I suggest we continue this conversation in WICG/EventListenerOptions#20 since it's (IMHO) a continuation of the same debate.

Contributor

RByers commented Sep 23, 2015

Ok, I suggest we continue this conversation in WICG/EventListenerOptions#20 since it's (IMHO) a continuation of the same debate.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Nov 10, 2015

Member

@RByers what is the plan for this feature?

Member

annevk commented Nov 10, 2015

@RByers what is the plan for this feature?

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Nov 10, 2015

Contributor

@annevk Sorry for the delay, we're still working on it (I've just bee caught up in some other things). @dtapuska is actively working on the blink implementation. I expect to be able to make the spec work here my top priority in a couple weeks.

Contributor

RByers commented Nov 10, 2015

@annevk Sorry for the delay, we're still working on it (I've just bee caught up in some other things). @dtapuska is actively working on the blink implementation. I expect to be able to make the spec work here my top priority in a couple weeks.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Nov 30, 2015

Contributor

Ok @annevk, I've finally reworked this pull request according to your suggestions in WICG/EventListenerOptions#20. WDYT?

Contributor

RByers commented Nov 30, 2015

Ok @annevk, I've finally reworked this pull request according to your suggestions in WICG/EventListenerOptions#20. WDYT?

@RByers RByers changed the title from Add EventListenerOptions to Add EventListenerOptions and passive event listeners feature Dec 2, 2015

@RByers RByers changed the title from Add EventListenerOptions and passive event listeners feature to Add EventListenerOptions and passive event listeners Dec 2, 2015

Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Dec 15, 2015

Contributor

Thanks for the review! I've updated the pull request based on your feedback. I assume I should avoid squashing all the commits until the review is done and we're ready to merge.

Contributor

RByers commented Dec 15, 2015

Thanks for the review! I've updated the pull request based on your feedback. I assume I should avoid squashing all the commits until the review is done and we're ready to merge.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Dec 16, 2015

Member

Feel free to rebase and squash once you're confident it's in a good shape and I'll just do another pass. Might be easier.

Member

annevk commented Dec 16, 2015

Feel free to rebase and squash once you're confident it's in a good shape and I'll just do another pass. Might be easier.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Dec 16, 2015

Contributor

Ok I think the only thing left is what exactly we want to cover in the "observing event listeners" section. Let's keep iterating on that, then once you're happy I'll rebase/squash (which I think will cause all the line-by-line discussions to disappear from GitHub :-( ).

Contributor

RByers commented Dec 16, 2015

Ok I think the only thing left is what exactly we want to cover in the "observing event listeners" section. Let's keep iterating on that, then once you're happy I'll rebase/squash (which I think will cause all the line-by-line discussions to disappear from GitHub :-( ).

Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
present in <var>options</var> with value true, then set <var>capture</var> to true.
<li>If <var>options</var> is a dictionary and <code>{{EventListenerOptions/passive}}</code> is
present in <var>options</var> with value true, then set <var>passive</var> to true.

This comment has been minimized.

@annevk

annevk Jan 1, 2016

Member

Since these four steps are repeated below I feel like we should introduce an abstract operation that returns two values for capture and passive given a dictionary or boolean.

@annevk

annevk Jan 1, 2016

Member

Since these four steps are repeated below I feel like we should introduce an abstract operation that returns two values for capture and passive given a dictionary or boolean.

This comment has been minimized.

@RByers

RByers Jan 4, 2016

Contributor

I attempted that here and I agree it looks cleaner, thanks! I couldn't find another example of returning multiple values, is what I've done precise enough? Any suggestion for a term better than "normalize" (which could perhaps be confused with Node.normalize)?

@RByers

RByers Jan 4, 2016

Contributor

I attempted that here and I agree it looks cleaner, thanks! I couldn't find another example of returning multiple values, is what I've done precise enough? Any suggestion for a term better than "normalize" (which could perhaps be confused with Node.normalize)?

This comment has been minimized.

@annevk

annevk Jan 4, 2016

Member

"flatten" perhaps? What you did seems great. Returning multiple values in English feels quite natural and I've done it before without confusing anybody.

@annevk

annevk Jan 4, 2016

Member

"flatten" perhaps? What you did seems great. Returning multiple values in English feels quite natural and I've done it before without confusing anybody.

This comment has been minimized.

@RByers

RByers Jan 4, 2016

Contributor

Thanks. Sure "flatten" sounds better to me - done.

@RByers

RByers Jan 4, 2016

Contributor

Thanks. Sure "flatten" sounds better to me - done.

Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
Show outdated Hide outdated dom.bs Outdated
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 5, 2016

Member

(Sorry, I was about to merge, but then I spotted that. Not sure why I didn't catch it earlier.)

Member

annevk commented Jan 5, 2016

(Sorry, I was about to merge, but then I spotted that. Not sure why I didn't catch it earlier.)

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 5, 2016

Member

The only other thing that looks a bit odd is the wrapping. I can clean that up I suppose.

Member

annevk commented Jan 5, 2016

The only other thing that looks a bit odd is the wrapping. I can clean that up I suppose.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jan 5, 2016

Contributor

The only other thing that looks a bit odd is the wrapping. I can clean that up I suppose.

Looks like the pattern is to use ~100 except in <pre> and <code> blocks, right? I'm fixing that now.

Contributor

RByers commented Jan 5, 2016

The only other thing that looks a bit odd is the wrapping. I can clean that up I suppose.

Looks like the pattern is to use ~100 except in <pre> and <code> blocks, right? I'm fixing that now.

Add EventListenerOptions and passive event listener feature
This introduces an EventListenerOptions dictionary which can
be used to explicitly specify options to addEventListener and
removeEventListener.

This also introduces a "passive" option, which disables the
ability for a listener to cancel the event.

See https://github.com/RByers/EventListenerOptions/blob/gh-pages/explainer.md
for a high-level overview, and
https://github.com/RByers/EventListenerOptions/issues?q=is%3Aissue
for most of the debate that went into the design.
@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jan 5, 2016

Contributor

Ok, re-wrapped all lines I touched to 100 columns (except <pre> and <code> blocks).

Contributor

RByers commented Jan 5, 2016

Ok, re-wrapped all lines I touched to 100 columns (except <pre> and <code> blocks).

annevk added a commit that referenced this pull request Jan 6, 2016

Add EventListenerOptions and passive event listener feature
This introduces an EventListenerOptions dictionary which can
be used to explicitly specify options for addEventListener()
and removeEventListener().

This also introduces a "passive" option, which disables the
ability for a listener to cancel the event.

See https://github.com/RByers/EventListenerOptions/blob/gh-pages/explainer.md
for a high-level overview, and
https://github.com/RByers/EventListenerOptions/issues?q=is%3Aissue
for most of the debate that went into the design.

PR: #82
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 6, 2016

Member

Landed as 253a21b.

Member

annevk commented Jan 6, 2016

Landed as 253a21b.

@annevk annevk closed this Jan 6, 2016

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 6, 2016

Member

Thank you!

Member

annevk commented Jan 6, 2016

Thank you!

@RByers RByers deleted the RByers:event-listener-options branch Sep 27, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment