On Wed, Jul 8, 2015 at 9:12 PM, Rick Byers <rby...@chromium.org> wrote: > [Cross-posted to www-...@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