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 11:30:31 -0400
Message-ID: <CAFUtAY8z2GNBBAyWsHWRAHO_Hn3vqQuit1wWGoQueQqZ--rvyQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>, Philip J├Ągenstedt <philipj@opera.com>, James Ross <w3c-20040125@james-ross.co.uk>
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.

> If we can get consensus on the basic approach, then I'd be happy to rework
> > my proposal in the form of a pull-request and move all issue tracking to
> > whatwg/dom.  There's probably no point in doing that until we have an
> > agreement on the basic API shape, right?
>
> Fair.
>
>
> --
> https://annevankesteren.nl/
>
Received on Thursday, 9 July 2015 15:31:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 15:31:18 UTC