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

On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers <> wrote:

> On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking <> wrote:
>> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky <> wrote:
>> > On 7/9/15 1:32 PM, Rick Byers wrote:
>> >>
>> >> Done.  How does example 2 look now?
>> >>
>> >>
>> >
>> > 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 (  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 (,
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:
> 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