- From: Rick Byers <rbyers@chromium.org>
- Date: Thu, 9 Jul 2015 15:09:12 -0400
- To: Elliott Sprehn <esprehn@chromium.org>
- Cc: WHATWG <whatwg@whatwg.org>, Philip Jägenstedt <philipj@opera.com>, Jonas Sicking <jonas@sicking.cc>, James Ross <w3c-20040125@james-ross.co.uk>
On Thu, Jul 9, 2015 at 2:59 PM, Elliott Sprehn <esprehn@chromium.org> wrote: > > On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers <rbyers@chromium.org> wrote: > >> On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> ... >> >> 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 >> >> > I don't like making this specific to scrolling, that doesn't explain what > it really means in terms of the capabilities of the event handler. We > probably want to use this for other event types where we want to change the > time the event dispatches based on if you require the ability to cancel or > not as well. > Yeah, that's a good point. Do you have some specific ideas in mind here? I'm probably too narrowly stuck in input-land :-) > > - E >
Received on Thursday, 9 July 2015 19:10:07 UTC