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

On Wed, Jul 8, 2015 at 12: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.

I like it!  I appreciate in general the upgrade of the third
addEventListener() argument from a boolean to an options bag, as that
was a really annoying wart in the API.  Makes specifying capture more
readable.

The new mayCapture argument makes a lot of sense, too.  It's very
frustrating having to deoptimize scrolling and similar things just
because the author *might* cancel the scroll; indicating that you
definitely won't, so we can keep it on the optimized path, is great.

~TJ

Received on Wednesday, 8 July 2015 19:46:38 UTC