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 13:32:37 -0400
Message-ID: <CAFUtAY-PPviUQZMZmiHNit0808TaArL8x7yTF4ehMi8vhFdJkA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg@lists.whatwg.org
On Thu, Jul 9, 2015 at 12:47 PM, Rick Byers <rbyers@chromium.org> wrote:

> On Thu, Jul 9, 2015 at 12:40 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> On 7/9/15 8:42 AM, Philip J├Ągenstedt wrote:
>>> Would there be any way to feature detect support for
>>> EventListenerOptions as the third
>>> argument?
>> Yes.  You call addEventListener and pass an object that has getters for
>> the properties you care about detecting.  If those getters get invoked, the
>> browser knows about those dictionary properties.
> Ah, perfect - I hadn't thought of that!  Thanks!  I'll change the spec for
> that now (https://github.com/RByers/EventListenerOptions/issues/16).

Done.  How does example 2 look now?

 Also, I think that this would make good sense as part of DOM itself,
>> This spec requires changes to DOM anyway, because the spec as written is
>> not valid IDL: It's creating two overloads that can both be called with two
>> arguments.  So we'll need to remove the "optional" annotation from the
>> boolean arg that's already in DOM when we add this new overload. That
>> doesn't seem like a problem.
> Yeah, plus there's the whole interaction with the 'capture' variable (spec
> should probably talk about a single 'options' variable with members like
> 'capture' every place it refers to the 'capture' variable)..  I knew I'd
> never be able to spec it properly on it's own, just enough to get the point
> across clearly.
Received on Thursday, 9 July 2015 17:33:23 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:33 UTC