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

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? Speaking
of that, having a new function makes it an option to let mayCancel be
false by default, compat-wise at least.

Philip

Received on Thursday, 9 July 2015 15:40:33 UTC