Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

Let me try to summarize the primary debate around this API so far.  There
are (at least) two major questions which I think block creating a proper
pull request for suggesting concrete changes to the spec:

1) Should we extend the existing addEventListener API or change the API
names (and perhaps other things) completely.
https://github.com/RByers/EventListenerOptions/issues/18

2) Should mayCancel=false listeners always get an Event with
cancelable=false, or is this "just a hint" such that all listeners still
get the same event with the same properties.
https://github.com/RByers/EventListenerOptions/issues/2

Unfortunately I'm on vacation without a computer for the next 1.5 weeks
(Anne, I'll be driving through Switzerland - it's really tempting to track
you down and buy you some beer so we can discuss this F2F, but sadly my
family wouldn't enjoy that nearly as much as I would <grin>).  I'm sure
you'll all reach consensus in my absence :-).  I'm cc'ing Dave on my team
who expects to start prototyping something in blink soon.  I've given most
of you (or those whose GitHub accounts I could find) contributor access to
this repo - feel free to land edits if the desire arises for any reason.

Thanks,
   Rick

On Wed, Jul 8, 2015 at 3:12 PM, Rick Byers <rbyers@chromium.org> wrote:

> [Cross-posted to www-dom@w3.org - please let me know if there's a better
> way to account for the DOM spec duality]
>
> In Chromium we've long worked hard at maximizing  scroll performance, with
> scroll-blocking DOM events (wheel and touchstart in particular) being by
> far the biggest source of scroll jank.
>
> I've been talking about this problem off-and-on for several years with
> various folks including the Pointer Events Working Group, engineers of
> other browser vendors, and engineers working on popular libraries that are
> a source of such scroll-blocking event handlers (eg. Google Ads and
> Google Analytics).
>
> I've now written a relatively formal (but still sloppy by W3C standards)
> concrete spec for extending the DOM event model
> <http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html> to
> address this problem and would like to solicit feedback.  It's probably
> most constructive to discuss specific issues on GitHub
> <https://github.com/RByers/EventListenerOptions/issues>, but I'd
> appreciate any high-level feedback here by e-mail too.  Please feel free to
> submit pull requests for eg. editorial improvements.
>
> Once there's a bit more consensus on the API shape, I plan to write a
> polyfill and tests and then begin a prototype implementation in Chromium.
> We have some initial evidence to believe that this (in partnership with a
> few key library authors) can make a substantial improvement to the user
> experience on mobile.  I hope to be able to share more concrete data on the
> real-world performance impact, but there's obviously a chicken and egg
> problem here.
>
> Thanks,
>    Rick
>

Received on Friday, 10 July 2015 19:13:06 UTC