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