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

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
<https://github.com/rbyers/EventListenerOptions>.

>
>
>
> -Olli
>

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