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

On 04/21/2015 08:00 AM, Olli Pettay wrote:
> 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});
>
>

...but unfortunately that is not backwards compatible. If we could find a nice backwards compatible syntax.
addEventListener("wheel", listener, true, { preventDefault: "never" }); would behave fine, but is a bit long.
Would it be good enough?


>
>
>> 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:25:12 UTC