W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2015

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

From: Rick Byers <rbyers@chromium.org>
Date: Wed, 8 Jul 2015 16:43:09 -0400
Message-ID: <CAFUtAY-K9kpWab44g0UQ+aRn_MtJM=fQGPxUXH1jcvyAnG82qA@mail.gmail.com>
To: Olli Pettay <olli@pettay.fi>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: whatwg@whatwg.org
On Wed, Jul 8, 2015 at 4:04 PM, Olli Pettay <olli@pettay.fi> wrote:

> On 07/08/2015 10:12 PM, Rick Byers 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

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.

Excellent, thank you!

> The basic idea looks good to me, as I said in, hmm, pointer-events?
> mailing list.

Thanks!  Yep, I've got a link to our thread in the repo README

> -Olli
Received on Wednesday, 8 July 2015 20:43:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 July 2015 20:43:55 UTC