Re: Non-scroll-blocking wheel events listeners / relationship to PEWG?

On Tue, Apr 21, 2015 at 9:43 AM, Olli Pettay <olli@pettay.fi> wrote:

> On 04/15/2015 08:31 AM, Rick Byers wrote:
>
>> It's common for libraries (eg. ads frameworks) to want to passively track
>> some notion of user interaction with the page.  For touch, Pointer Events is
>> a good API for this because the event listeners don't block scrolling.
>> But what about for wheel events?  Adding a document wheel event handler for
>> this (when none existed previously) is bad for scroll performance.
>>
>
> I wonder how bad the performance issues actually are here. Comparing to
> pointer events, wheel events fire rarely, and there are just couple of them
> in a row. So an implementation could have enough time to hit test and
> dispatch an event before the next animation frame tick.
> (I'm a bit worried making the platform more complicated than it needs to
> be.)


Why do you say there's just a couple of them in a row?  I'm thinking
primarily of scrolling on high-quality touchpads here (eg. macbooks,
chromebooks).  There wheel events are similar to touchmove events in terms
of frequency and duration during a scroll.  That said, there are some big
differences:
1) wheel scrolling tends to be done on much faster devices than touch
scrolling
2) indirect manipulation is more forgiving psychologically than direct
manipulation (since with touch your finger acts as a point of reference
that makes at least latency substantially more noticeable, but I'm not sure
how it affects the perception of smoothness).

So I agree it may not be that important.  But as we look to provide control
over the blocking behavior of touch and scroll handlers (eg. scroll-blocks-on
proposal
<https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit>),
I'm trying to consider wheel handlers also for consistency and
completeness.

Should PEWG consider trying to address this scenario?
>>
>> One option (that I think we've discussed a bit in some form) would be to
>> have a new non-blocking event ('pointerwheel' maybe?) and a new
>> 'wheel-action' CSS property (similar to touch-action) that declaratively
>> says what sort of wheel movement should cause scrolling.  This would be most
>> like pointer events, but adding new event types for this seems
>> unfortunate (now what about keyboard scrolling?).
>>
> well, keyboard scrolling doesn't cause wheel events either.


Right, but the same problem exists there in theory.  Perhaps there should
be some mechanism to permit keyboard event listeners that won't block
scrolling?  But this is even less important than the wheel case IMHO.

Another option would be to augment event handler registration with an
>> options dictionary (instead of just the single 'capture' boolean).  Eg:
>> addEventListener('wheel', myHandler, {blocksScroll: false});
>>
> Definitely not this. This is not a strong enough case to change an API
> which has existed for 15+ years, IMO.
>

Would you feel any better about this if the API had a new name?  Although I
share your gut reaction that we shouldn't be messing with addEventListener,
in debates internally I haven't been able to formulate a clear technical
argument against extending addEventListener to have some mechanism for
additional options.  If what the developer wants to say is "I want to
observe wheel events, but I'm never going to call preventDefault on them so
please don't block scrolling" then it does feel most natural to allow them
to say that at event handler registration time somehow.  Any suggestion for
how such a mechanism should look?

A third option is to leave the event system unmodified and rely on a CSS
>> property to independently control when events block scrolling.  This is what
>> my 'scroll-blocks-on <
>> https://docs.google.com/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit#heading=h.wi06xpj70hhd>'
>> proposal does (for
>> which I've landed an experimental partial implementation in blink).  A
>> key downside here is the 'spooky action at a distance' between event
>> registration and CSS property application.  Eg. how to multiple
>> components each putting wheel handlers on the document effectively
>> co-ordinate on what
>> the combined effect on the document should be? For this particular
>> scenario (not one of the original goals of scroll-blocks-on) indicating
>> intent at
>> event registration time seems much better for composition.
>>
> But this would work with keyboard events too.
>
> In fact, what do we actually want here. wheel/key event handling, or
> notification about what user just did?
> So, would some kind intentional event work here?
>
> addEventListener("userIntention", function(e) {
>   if (e.intention == "scroll") {
>     // do something
>   }
> });
> Or should "scroll" event be extended so that it tells what triggered the
> action? That can be a bit difficult to implement, but might be rather nice
> to have.
>

The main use case I've got in mind is activity tracking.  Most ad
frameworks have some system (like it or not) of monitoring user activity
(where was the mouse cursor, where on the page is the user touching,
etc.).  Today this hurts scroll performance substantially.  Pointer events
solves this for touch (although I'm not sure yet whether that's good enough
- we may still pursue a solution with touch events), but no-one has
proposed a good design that could also address the touchpad case
(scroll-blocks-on gets awkward in the composition cases - all components on
the page need to use some library/pattern to mediate the combination of
desires from the different components).

So for that use case, I don't think a scroll intention is really adequate.
We could have some generic 'user activity' intention that included a screen
co-ordinate, but that would quickly end up looking pretty redundant with
pointer events.


>
>
>
>> See some more chromium-specific debate here <
>> https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/4B7VFPZvHY0
>> >.
>>
>> Thoughts?  Out of scope for this group?
>>
>>
> Sounds like out of scope for this group, but I don't really mind whether
> discussed here or in WebApps.
>
>
> -Olli
>
>
>
>
>  Rick
>>
>
>