W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2015

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

From: Olli Pettay <olli@pettay.fi>
Date: Tue, 21 Apr 2015 06:43:55 -0700
Message-ID: <5536541B.30508@pettay.fi>
To: Rick Byers <rbyers@chromium.org>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
CC: Jared Duke <jdduke@chromium.org>, Nathaniel Duca <nduca@chromium.org>
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 

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


> Rick
Received on Tuesday, 21 April 2015 13:44:32 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 16 May 2015 00:31:59 UTC