- From: Rick Byers <rbyers@chromium.org>
- Date: Thu, 9 Jul 2015 15:06:09 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers <rbyers@chromium.org> wrote: > > On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking <jonas@sicking.cc> wrote: > >> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> > On 7/9/15 1:32 PM, Rick Byers wrote: >> >> >> >> Done. How does example 2 look now? >> >> >> >> >> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 >> > >> > Looks like it would work. Also looks kind of ugly because of the >> > object-truthiness bit, but I'm not sure there's any way to avoid that >> while >> > keeping the "overload a boolean and dictionary" setup. >> >> I'm not a fan of this approach. It'll be very hard to get users to opt >> in consistently to the faster behavior. Especially given that it >> requires much more typing. >> > Bigger picture, we're seriously exploring in chromium taking both a carrot and stick approach to the event-handler jank problem. Carrots are this new API, better devtools tooling highlighting the problem, etc. Sticks are more controversial so we're not ready to propose anything concrete yet. But imagine if particularly slow sites that haven't opted out of blocking handlers got some sort of unresponsive UI notification ( http://crbug.com/504904). The window-greying-out behavior introduced in Windows Vista had a very strong impact on developers motivation to invest in UI-thread responsiveness :-). Also Google search results already take page load time into account ( http://googlewebmastercentral.blogspot.ca/2010/04/using-site-speed-in-web-search-ranking.html), if we could reliably collect scroll jank performance I don't see why that also wouldn't be a good signal to use in search rankings (though this is only my personal opinion - no inside knowledge here at all). Anyway, suffice it to say that I fully agree we can't expect big wins in practice just by shipping this new API (no matter how simple we make it, though the simpler the better of course). But I'm still confident that having an API like this will open a lot of doors that together will lead to substantial user-experience improvements on the web. I think this probably depends on your position on the 'should > mayCancel=false be enforced' debate: > https://github.com/RByers/EventListenerOptions/issues/2 > > If you (like me) believe it's important to keep mayCancel=false listeners > from being able to cancel their events, then developers need to type a fair > bit more than just what this example shows for proper testing. Really they > need to use a small polyfill. If they're already depending on the polyfill > for Event.cancelable/preventDefault behavior, than what's a few more lines > for slightly more complex feature detection? > > To make this more concrete I can start whipping up a concrete polyfill and > tests. But I was hoping to settle the key design question in #2 first. > > >> / Jonas >> > >
Received on Thursday, 9 July 2015 19:06:56 UTC