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 15:09:12 -0400
Message-ID: <CAFUtAY-ySbu8NmKLjxp-RSY1R8NF+yjoK5GJ72Vii3ZwhP3wbg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 19:10:07 UTC