On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers <rby...@chromium.org> wrote:
> On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers <rby...@chromium.org> wrote:
>>
>>
>> On Thu, Jul 9, 2015 at 9:05 AM, James Ross <w3c-20040...@james-ross.co.uk>
>> wrote:
>>>
>>> > Date: Thu, 9 Jul 2015 14:42:07 +0200
>>> > From: phil...@opera.com
>>> >
>>> > I think this looks like a very promising approach. Would there be any
>>> > way to feature detect support for EventListenerOptions as the third
>>> > argument? It seems like a problem that addEventListener(type,
>>> > callback, { mayCancel: false }) would be treated as
>>> > addEventListener(type, callback, true) in existing browsers.
>>>
>>>
>>> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#extensions-to-the-event-interface
>>> and
>>> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#examples
>>> example 2 are intended to cover this.
>>
>>
>> Right, thanks. What I've suggested is kind of weird though. Olli raises
>> a good point that we should discuss general dictionary-member feature
>> detection patterns in the abstract before committing to something like this.
>> I'd love other opinions / ideas on the bug.
>
>
> I should perhaps add that I'd hope developers don't really need to use the
> pattern in example #2 explicitly. Instead I expect they'd mostly rely on a
> simple polyfill (which I'll take an initial crack at writing once the API
> shape settles down a bit).
I see, the answer is getSupportedListenerOptions(). Seems slightly
peculiar, but would work. Should be on EventTarget if anything,
though.
