On Thu, Jul 9, 2015 at 9:49 AM, Philip Jägenstedt <phil...@opera.com> wrote:
> 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. > Added that suggestion to the bug: https://github.com/RByers/EventListenerOptions/issues/16#issuecomment-119983345. I agree it's peculiar - I'd love to hear other ideas!