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

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


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

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


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




>
> 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 13:44:32 UTC