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

On 04/21/2015 07:10 AM, Rick Byers wrote:
> On Tue, Apr 21, 2015 at 9:43 AM, Olli Pettay <olli@pettay.fi <mailto: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 comparing to touch events for example. But you're right, pixel level wheel events happen rather often.

> 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.


Would wheel+ctrl behave differently to wheel? Or other event+modifier combinations? (I think events should be for consistency dispatched the same way, 
either always async or always sync, whether or not there are modifiers)

>
>         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?
Not really

> 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"
Aha, if you formulate the behavior in a bit different way, then it becomes more generic...
So, "I'm not going to call preventDefault()" might be such, useful also in other cases than just with wheel.
A bit odd API, but might be useful, really useful.

enum PreventDefaultHints {
   "never"
   ""
};
addEventListener("wheel", listener, { preventDefault: "never",
                                       capture: true});




> 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.

well, pointer events don't deal with key events.

I can see non-ad use cases for user-activity events too (do some heavy clean up in the page while user isn't interacting with it and there are no rAF 
callbacks called and so.)


>
>
>
>
>
>         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
>
>
>

Received on Tuesday, 21 April 2015 15:01:14 UTC