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:15:29 -0400
Message-ID: <CAFUtAY-mPnM8UrZpK1smeUE4d8GCqevzYJ5z+J+bA-WyqbO0Zw@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:05 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers <rbyers@chromium.org> wrote:
> > I'd love to hear other ideas!
> Well, we have had some discussions in the past about introducing a
> better event API:
>   https://gist.github.com/annevk/5238964
> Maybe the time has come...

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.

What do you think about an incremental path?  I don't see any fundamental
reason that things need to change drastically.

(I agree with Philip that if we add this it would need to become part
> of whatwg/dom. That seems like a better place for any GitHub
> discussion too.)

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?

> --
> https://annevankesteren.nl/
Received on Thursday, 9 July 2015 15:16:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 15:16:26 UTC