- From: Rick Byers <rbyers@chromium.org>
- Date: Thu, 9 Jul 2015 14:57:08 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > On 7/9/15 1:32 PM, Rick Byers wrote: > >> > >> Done. How does example 2 look now? > >> > >> > http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2 > > > > Looks like it would work. Also looks kind of ugly because of the > > object-truthiness bit, but I'm not sure there's any way to avoid that > while > > keeping the "overload a boolean and dictionary" setup. > > I'm not a fan of this approach. It'll be very hard to get users to opt > in consistently to the faster behavior. Especially given that it > requires much more typing. > I think this probably depends on your position on the 'should mayCancel=false be enforced' debate: https://github.com/RByers/EventListenerOptions/issues/2 If you (like me) believe it's important to keep mayCancel=false listeners from being able to cancel their events, then developers need to type a fair bit more than just what this example shows for proper testing. Really they need to use a small polyfill. If they're already depending on the polyfill for Event.cancelable/preventDefault behavior, than what's a few more lines for slightly more complex feature detection? To make this more concrete I can start whipping up a concrete polyfill and tests. But I was hoping to settle the key design question in #2 first. > / Jonas >
Received on Thursday, 9 July 2015 18:58:07 UTC