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

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

From: Rick Byers <rbyers@chromium.org>
Date: Thu, 9 Jul 2015 14:52:54 -0400
Message-ID: <CAFUtAY_LigXiwQjsCizhiMAc2dP5XPRL9RCmCzd=d2VWkvRy9w@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHATWG <whatwg@whatwg.org>, Philip J├Ągenstedt <philipj@opera.com>, James Ross <w3c-20040125@james-ross.co.uk>
On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> >> Speaking
> >> of that, having a new function makes it an option to let mayCancel be
> >> false by default, compat-wise at least.
> >
> > That's a good question regardless of which approach we take. Filed
> > https://github.com/RByers/EventListenerOptions/issues/17
>
> I definitely think that if we're going to have any chance of moving
> significant portions of the web to have better performance, we need
> things to be fast by default, and then opt-in to slower behavior.
>
> And the more we can simply point to "these APIs are fast, use these,
> those APIs are slow, don't use those" the better. It should be very
> clear when you're falling off the fast path.
>

I agree 100% with this principle.  Changed mayCancel to default to false:
https://github.com/RByers/EventListenerOptions/commit/b6ca043c9f13cea773a9338d580a0ebc24ea8140
.

This raises a related question though - is the 'mayCancel' name strong
enough to indicate performance implications to developers?  I personally
still kind of like the 'blocksScroll' design instead:
https://github.com/RByers/EventListenerOptions/issues/14


> / Jonas
>
Received on Thursday, 9 July 2015 18:53:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 18:53:47 UTC