- From: Rick Byers <rbyers@chromium.org>
- Date: Thu, 9 Jul 2015 14:52:54 -0400
- 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