- From: Rick Byers <rbyers@chromium.org>
- Date: Thu, 9 Jul 2015 09:44:26 -0400
- To: James Ross <w3c-20040125@james-ross.co.uk>
- Cc: WHATWG <whatwg@whatwg.org>, Philip Jägenstedt <philipj@opera.com>
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers <rbyers@chromium.org> wrote:
>
> On Thu, Jul 9, 2015 at 9:05 AM, James Ross <w3c-20040125@james-ross.co.uk>
> wrote:
>
>> > Date: Thu, 9 Jul 2015 14:42:07 +0200
>> > From: philipj@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 <https://github.com/RByers/EventListenerOptions/issues/16>
> 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
> <https://github.com/RByers/EventListenerOptions/issues/16>.
>
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).
Received on Thursday, 9 July 2015 13:45:19 UTC