W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2015

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

From: Rick Byers <rbyers@chromium.org>
Date: Thu, 9 Jul 2015 14:57:08 -0400
Message-ID: <CAFUtAY-UJs0eO9WcngraXvEVkacvJJW5f7vd=_Fmnfvb80v85A@mail.gmail.com>
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:

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

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 18:58:08 UTC