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

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 9 Jul 2015 14:42:07 +0200
Message-ID: <CAMQvoCnBDaXBA5fDqUSQUvV8gWxxzY5n3teyXcAw2ms6BESEhQ@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>, Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>
On Wed, Jul 8, 2015 at 9: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 think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.

Also, I think that this would make good sense as part of DOM itself,
in particular to get rid of the "calls to preventDefault will be
ignored" patching of DOM algorithms. https://github.com/whatwg/dom is
open for pull requests, or at least I've done some trivial ones.

Anne, what do you think?

Received on Thursday, 9 July 2015 12:42:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 12:42:38 UTC