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 12:30:38 -0400
Message-ID: <CAFUtAY_BuZk0Ty=++rA462iqAvW6yKrYf7ga-Z9HR_P5Ug=w4A@mail.gmail.com>
To: Philip J├Ągenstedt <philipj@opera.com>
Cc: WHATWG <whatwg@whatwg.org>, James Ross <w3c-20040125@james-ross.co.uk>
On Thu, Jul 9, 2015 at 11:40 AM, Philip J├Ągenstedt <philipj@opera.com>
wrote:

> On Thu, Jul 9, 2015 at 5:30 PM, Rick Byers <rbyers@chromium.org> wrote:
> > On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >>
> >> On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers <rbyers@chromium.org> wrote:
> >> > I think there's a big opportunity to substantially improve scroll
> >> > performance on the web in the relatively short term by doing something
> >> > incremental.  I.e. I'm pretty sure I can get major scroll-blocking
> >> > libraries
> >> > like Google Analytics to opt into the pattern proposed here in a
> >> > relatively
> >> > short timeframe.  I'm much less sure I could get them to switch to a
> >> > completely new event API in any sort of reasonable timeframe.
> >>
> >> Either way they need to branch their code, no?
> >
> >
> > Yeah, but the way it's defined now it's 2 small lines of extra JS for
> them:
> >
> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
> >
> > We've also already got a lot of support for this incremental approach
> from
> > some IE and Mozilla folks (I've reached out to Safari folks privately,
> but
> > nothing public yet).  I probably should have reached out to this list
> long
> > ago - sorry about that (I was mainly focused from the input scenario
> side,
> > for quite awhile it was looking like we'd prefer a CSS API instead of
> > something like this).
> >
> > That said, I like the look of your proposal (though not sure what exactly
> > filter and marker would do).  If you think it's something that's
> practical
> > accomplish in a reasonable time frame then I'm all for it.  Is it fully
> > polyfillable? I just don't think this tiny tweak should be the thing that
> > necessitates such a major API change.
> >
> >> > What do you think about an incremental path?  I don't see any
> >> > fundamental
> >> > reason that things need to change drastically.
> >>
> >> Overloading a boolean argument with a dictionary seems bad. And if we
> >> are to have a new API anyway, we might as well pick the better names.
> >
> >
> > We could just add a 4th argument for now (a dictionary or even just a
> > boolean) if you think that's better to keep the changes absolutely
> minimal
> > until this larger rework can be done.
>
> How about if we just pick nice and short names with a dictionary as
> one of the arguments, but initially limit these new APIs to exactly
> the existing behavior plus the mayCancel bit? We can tackle other
> nice-to-haves later, unless there's some default behavior of the
> existing APIs that would be worth changing at the same time?


That seems like a nice incremental compromise.  Using a new name for
addEventListener will help address some of the feature detection /
compatiblity concerns too.  Filed
https://github.com/RByers/EventListenerOptions/issues/18.

Speaking
> of that, having a new function makes it an option to let mayCancel be
> false by default, compat-wise at least.
>

That's a good question regardless of which approach we take. Filed
https://github.com/RByers/EventListenerOptions/issues/17


> Philip
>
Received on Thursday, 9 July 2015 16:31:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 16:31:25 UTC