Re: [pointerevents] Clarify whether touch contact must fire a `pointerrawupdate` event (#373)

Thank you very much for the prompt answer:

> when a touch "appears" on a touchscreen the button state is not really changed, as the pointer only just appeared and wasn't there to begin with before the finger was on the touchscreen. so as a layperson, i wouldn't expect a pointerrawupdate event to be fired there as it's not a change as such, but an appearance of a new pointer that yes happens to have a particular button state.

Good point.

Some more context as to why this is of interest to me:

At the moment, listening to `pointerrawupdate` events is the only way to implement touch behaviours on top of the default ones, controlled with `touch-action`. Say that I would like to determine the position of the pointer, while still allowing vertical scrolling. As the user starts scrolling up and down with their finger, an initial `pointerdown` and a few `pointermove` updates would fire, ended with a `pointercancel` event. However I discovered that on Chrome, `pointerrawupdate` are emitted continuously even when `touch-action` preserves `pan-y`.

Yet, there is no way to know when the finger is lifted from the digitizer, as neither `pointerup` nor `pointerrawupdate` fire when this happens. I therefore cannot implement the specific behaviour I am interested in (natural panning on overscrolling) .

> Our original intention of pointerrawupdate was to disable this raf aligning behavior which was originally introduced to save main thread redundant work that was not needed in most cases.

This sounds like I am not using `pointerrawupdate` for its intended purpose. Should the events then fire even when the default touch behaviour of the user agent takes over? 

GitHub Notification of comment by yacinehmito
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 12 May 2021 07:29:45 UTC