[pointerevents] Proposal: a way of tracking pointer position on pan/zoom touch-action (#339)

samuelmtimbo has just created a new issue for https://github.com/w3c/pointerevents:

== Proposal: a way of tracking pointer position on pan/zoom touch-action ==
I understand one of the main purposes of "pointercancel" is to signal the user agent will handle panning/zooming/etc; and will no longer fire pointer events, which makes sense, but there are genuine situations where this might be limiting. Let me try to exemplify. 

This might be a very particular scenario, but I would like to bring it to the table: some applications rely solely on Pointer Events to track which pointers are "visible" on the screen and such tracking might be visually represented, say by rendering an element on at the current pointers(s) positions(s). This might be done for an aesthetic and/or usability reason. This will work fine most of the time but not when scrolling an overflown element (a list, for instance) on a touch device. Moreover, basically **it won't work whenever the browser "handles a touch-action"**.

Full disclosure: I am developing a game-like web app where I envisioned a "bot", an eye-like creature that basically follows all the pointers on the screen like he is omniscient of what the user is doing... There is this expectation break when the user performs panning on a list, say a common usage search list, which intuitively makes no sense because the finger is clearly still touching the screen. 

I can think of some workarounds, but all of them feel hardcore: 

1) Use CSS `touch-action: none;` on absolutely all elements and implement scrolling manually in JavaScript using Pointer Events - this is a complex and error-prone task and probably will come with a performance penalty. I am also not sure if it would be possible to correctly replicate the "scroll momentum" browser behavior;

2) Use Pointer Events alongside Touch Events (say by registering "touchmove"/"touchend" after "pointercancel")  - this would lead to complex and duplicated logic and repeated state since it would be hard to associate the canceled pointer with a subsequent touch (there is no direct correspondence between Pointer Events `pointerId` and Touch `identifier`, for instance);

3) Do not use Pointer Events and use a combination of Mouse Events and Touch Events instead - this would totally go against the point of Pointer Events IMHO (and there is a chance it would also be unfeasible all things considered);

Am I missing something?

I would like your help thinking about a non-breaking alternative. I am sorry for my lack of understanding of the implementation details, but here are some possibilities that come to my mind: 

1) Adding a flag on "pointerdown" signaling to the user agent "I still want to receive pointer events after you start handling a touch action". That could make the user agent not automatically fire "pointercancel"/"pointerup" at all in that case, but still move on handling the touch action. I am imagining something syntactically similar to `addEventListener` `passive` property;

2) Firing additional events such as "touchactionstart", "touchactionmove", "touchactionend" associated with any of the previously canceled pointers (by `pointerId`);

I recognize it might be hard to feel empathetic with this need, but I don't see any other way around. I hope I can help further.

Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/339 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 18 November 2020 18:55:14 UTC