Add EventListenerOptions and passive event listeners #82
Conversation
|
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. |
|
Basically, the way this is written I don't see much room for optimizations, unless you're doing something that's not allowed. |
|
It's addressed by what @smaug--- said. I.e. whether or not a particular event is 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? |
|
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.) |
|
Ok, I suggest we continue this conversation in WICG/EventListenerOptions#20 since it's (IMHO) a continuation of the same debate. |
RByers
force-pushed
the
event-listener-options
branch
from
f440630
to
29925e7
Compare
|
@RByers what is the plan for this feature? |
RByers
force-pushed
the
event-listener-options
branch
from
cddfc43
to
7e05d12
Compare
|
Ok @annevk, I've finally reworked this pull request according to your suggestions in WICG/EventListenerOptions#20. WDYT? |
RByers
force-pushed
the
event-listener-options
branch
from
7e05d12
to
49ba2a3
Compare
RByers
changed the title
RByers
changed the title
| just a boolean, in which case it determines the value of the <b>capture</b> option. | ||
|
|
||
| When set to true, | ||
| the <var>capture</var> option prevents <b>callback</b> from being invoked when |
There was a problem hiding this comment.
<var>capture</var> is no longer a variable so this seems wrong.
There was a problem hiding this comment.
How about the <b>capture</b> member of <var>options</var>? Or do you prefer simply the capture option?
There was a problem hiding this comment.
I think "<var>options</var>' <code>capture</code> member" is what is typically used.
|
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. |
|
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. |
|
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 :-( ). |
RByers
force-pushed
the
event-listener-options
branch
from
d4322fe
to
c01304d
Compare
| {{Event/preventDefault()}} was invoked | ||
| while the {{Event/cancelable}} attribute | ||
| value is true, and false otherwise. | ||
| {{Event/preventDefault()}} was used successfully to indicate cancellation. |
There was a problem hiding this comment.
(Adding more nitpicky comments. Feel free to ignore for now.) s/used/invoked/ We don't want to omit mentioning when it returns false. The original text did that correctly.
There was a problem hiding this comment.
Whoops, must have lost this by accident somewhere along the line. Fixed.
| <h3 id=observing-event-listeners>Observing event listeners</h3> | ||
|
|
||
| <p>In general, developers do not expect the presence of an <a>event listener</a> to be | ||
| observable. The impact of an <a>event listener</a> is determined by its <b>callback</b>. |
There was a problem hiding this comment.
Throughout, there should only be a single space after a period.
RByers
force-pushed
the
event-listener-options
branch
from
b2fa94e
to
530c38b
Compare
|
|
||
| <li>Clear <var>event</var>'s <a>in passive listener flag</a>. | ||
|
|
||
| <li>If the call to {{EventListener/handleEvent()}} threw any exception, <a>report the exception</a>. |
There was a problem hiding this comment.
Are you sure this is correct? Reporting the exception is synchronous. Seems like you could circumvent the passive restriction by storing the event somewhere and then throwing.
There was a problem hiding this comment.
If reporting the exception is synchronous, then is it OK to just clear the passive listener flag afterwards (updated)? That would definitely be preferable, I was just thinking that wouldn't be possible.
There was a problem hiding this comment.
As far as I can tell that's fine. Where do you think it would break?
There was a problem hiding this comment.
I just wasn't thinking about it properly (thinking in terms of an algorithm with a 'throw' statement). Thanks for catching this, I agree it's better and I don't anticipate any implementation issue.
|
(Sorry, I was about to merge, but then I spotted that. Not sure why I didn't catch it earlier.) |
RByers
force-pushed
the
event-listener-options
branch
from
530c38b
to
d17e7f8
Compare
|
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 |
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
force-pushed
the
event-listener-options
branch
from
d17e7f8
to
0ad4e56
Compare
|
Ok, re-wrapped all lines I touched to 100 columns (except |
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
|
Landed as 253a21b. |
|
Thank you! |
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.