- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 9 Jul 2015 14:42:07 +0200
- 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? Philip
Received on Thursday, 9 July 2015 12:42:37 UTC