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 <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).