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

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

From: Rick Byers <rbyers@chromium.org>
Date: Wed, 15 Apr 2015 11:31:55 -0400
Message-ID: <CAFUtAY-jP8dt+ivvs+Zrdg1VTfKNLHodSraRcwv4K=HDU4yoYw@mail.gmail.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Cc: Jared Duke <jdduke@chromium.org>, Nathaniel Duca <nduca@chromium.org>
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.

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

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});

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.

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?

Rick
Received on Wednesday, 15 April 2015 15:33:02 UTC

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