Re: [pointerevents] Expose event for pinch gesture (#543)

First, I have to admit I did some tests on IE 11 --- it's not a good browser for now but it still has the great handling of touch inherited from Windows 8 era (I would test EdgeHTML or Metro IE if I had the old versions available...). I also tested on iPhone.

My computer supports 10 touch points and iPhone supports 5. More comments on handling touch:

- Pinch to zoom supports any number of fingers >= 2. On Windows IE and iPhone Safari, fingers and leave and re-enter, and pinch-to-zoom continues as soon as there are 2 fingers in touch. On both devices, I can initiate pinch-to-zoom with the maximum number of fingers.
- The task of handling two-finger scroll is not a separate one. Both IE and Safari support pinch-and-pan. The invariant is, when there are two fingers, the pixel pointed to (support this concept holds, although each touch input is often represented by an ellipse) by the two fingers remain the same pixel, and the canvas zooms and moves. Therefore, if the user holds the two fingers relatively still and moves both, then it's just pinch-and-pan with pinch zoom rate 100%.
- From my experience, the inertia on Windows and iOS feel almost the same.

By inertia on Windows, I mean Windows 8 Start screen, Windows Store apps, Metro IE, EdgeHTML, not the current Edge (Chromium). Chromium is a different blood-line and its touch support has been so-so. (Sidebar: Windows Phone and iOS have almost the same inertia mechanism, but Android is distinctly different --- no elastic over-scroll but a bubble --- is this some patent licensing issue?)

---

Back to the question at hand. I'll call the task of natively supporting and gluing together both user-agent gestures and custom gestures "coalescing".

One way to achieve coalescing is to standardize two sets of API, a touch event translator `T` and a touch event acceptor `A`.

An instance of `T` accepts touch event data incrementally, and after each feed, updates its internal state and output any recognized gestures and their amounts. (A gesture with amount is basically a `transform`.) Eventually, `T` accepts a final event, after which it can be repeatedly called to compute the inertia displacements (represented by gesture with amount) since each last call, until it finally decides there is no more movement. `T` encapsulates how the user agent will handle the input natively.

The usage of `T` is as follows. When a series of pointer events start, the developer creates a fresh instance. Each event in the series is then feeded into `T`, which then tells the developer a delta of the operation. The developer then decides to consume some deltas (e.g., zooming the map instance), and relay the other (e.g., scrolling the view port or pinch-zoom the view port --- we'll discuss this later). Eventually, the series of event end. The developer calls `requestAnimationFrame`, and in each animation frame callback, interrogates `T` the residual inertia displacements and process them like before. If `T` reports no displacement, then the process stops. Otherwise, the animation frame callback calls `requestAnimationFrame` again, repeating until the process stops.

The usage of `A` is as follows. This is a set of static methods. The developer can use it to instruct the user agent to act as if some touch gesture happened, e.g., perform a pinch-zoom, scroll the view port, etc. Preferably, scroll reported using this channel can be properly coalesced by the user agent and synchronized in animation frames. Importantly, currently there's no way to ask the user agent to do a pinch-zoom progammatically.

When `T` reports a delta and the developer decides this delta is the user agent's business, the developer calls into `A`.

---

With such API, one can reproduce the native behavior (with some performance penalty) as follows:

- `touch-events: none;`
- listen for pointer events
- in each series of pointer events, construct `T`, feed it the event data faithfully, and forwards all the deltas to `A`

It appears that such API is a cleaner solution than playing with all sorts of events and deciding to handle or not.

-- 
GitHub Notification of comment by GeeLaw
Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/543#issuecomment-2857120375 using your GitHub account


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

Received on Wednesday, 7 May 2025 05:38:49 UTC