Define the gesture and browser boundary
Use Pointer Events when a single input path across mouse, pen and touch fits the mechanic. Track the active pointer from pointerdown through movement and release, and ignore unrelated pointers unless multi-touch is intentional. Set touch-action on the game surface to preserve browser panning or pinch behavior that players still need; a blanket touch-action: none can remove browser zoom access.
For a drag mechanic, show a grabbed state immediately and update the object from the pointer position. For a tap, decide whether slight movement cancels activation and test that threshold on real touch devices. Scope the play surface’s gesture policy narrowly instead of applying it to the whole page.
Treat cancellation as a normal outcome
A pointer can be canceled when the browser takes over a gesture, the device changes state or the interaction otherwise stops. Clear the game’s pressed state on pointercancel just as you would after a completed release; otherwise a character can keep moving or a button can look permanently held. If the game captures a pointer, release that capture during cleanup.
Test a tap, slow drag, edge-started gesture and browser scroll attempt. Check that each action has clear feedback and leaving the surface cannot strand a control. MDN’s Pointer Events guide explains the shared pointer model and touch-action behavior.
Questions about touch controls for web games
Should a game disable all browser touch gestures?
Only when the play surface truly needs to own those gestures. Preserve browser panning or zoom where possible, and scope touch-action rules to the area whose interaction requires them.
What should happen after pointercancel?
End the in-progress game action and clear pressed or dragging state. Cancellation is an expected input outcome, so cleanup should be as deliberate as pointerup handling.