Touch Events

Touch events report changes to one or more contacts on a touch-sensitive surface. Handle contacts by identifier, clean up on both end and cancellation, and consider Pointer Events for new interfaces that need to support several input types.

Touch events report changes in contact with a touch-sensitive surface. The main phases are `touchstart`, `touchmove`, `touchend`, and `touchcancel`; a gesture may involve multiple fingers or a stylus.

A `TouchEvent` includes lists of touch points. `touches` represents contacts that are currently active, `targetTouches` covers active contacts associated with the event target, and `changedTouches` lists contacts changed by the current event. Each `Touch` has an `identifier` that can be used to associate it with later events, along with coordinates such as `clientX` and `clientY`.

For multi-touch interaction, process the contacts in `changedTouches` and maintain application state keyed by each contact's identifier. Remove a contact when it ends or is cancelled. A `touchcancel` can occur when the browser or operating system interrupts the interaction, so it should be handled as cleanup rather than ignored.

Calling `preventDefault()` may suppress browser behavior such as scrolling or compatibility mouse events, depending on event type, listener options, and browser behavior. Use it only when the interaction requires taking control, and account for passive listeners, where preventing the default is not allowed. CSS `touch-action` can express which gestures the browser may handle.

For most new interfaces that need to work with mouse, pen, and touch, consider Pointer Events instead. Touch events remain relevant when maintaining touch-specific code or supporting environments that depend on them; their availability is not uniform across browsers and devices.

Key points

• Touch interactions can have multiple simultaneous contact points.
• Use `changedTouches` to process contacts changed by the current event.
• Track ongoing contacts by `Touch.identifier`, not by list position.
• Handle `touchcancel` so interrupted contacts do not leave stale state.
• Use `preventDefault()` cautiously; consider passive listeners and `touch-action`.
• Prefer Pointer Events for many new interfaces that support multiple input types.

Interview questions

What are touch events, and which event types are commonly used?

Touch events are browser events for contact with a touch-sensitive surface. The lifecycle commonly includes `touchstart`, `touchmove`, and `touchend`, with `touchcancel` for an interrupted contact. A single event can contain information about multiple touch points, which makes them suitable for multi-touch gestures. For new cross-input code, I would usually evaluate Pointer Events as the unified alternative.

How do `touches`, `targetTouches`, and `changedTouches` differ?

`touches` describes all touch points currently active on the surface. `targetTouches` is limited to active touch points associated with the event target. `changedTouches` contains the points whose state changed in the current event, such as newly started, moved, or ended contacts. For handling a particular event, iterating `changedTouches` avoids treating every still-active contact as newly changed.

How would you track multiple simultaneous touches?

I would key active-contact state by each touch's `identifier`, rather than assuming that array position stays associated with a finger. On start, add the changed contacts; on move, update their state; on end or cancellation, remove them. This supports simultaneous touches and prevents stale state after an interrupted interaction. Coordinates should be interpreted consistently, for example using `clientX` and `clientY` for viewport-relative positions.

What are the risks of calling `preventDefault()` in a touch handler?

`preventDefault()` cancels an event's default browser action when cancellation is allowed. In touch handling, that may affect scrolling, zoom-related behavior, and compatibility mouse events, so calling it indiscriminately can break normal interaction. A passive listener cannot successfully cancel the default action. I would choose the narrowest event handling needed and consider CSS `touch-action` to declare which gestures the browser may perform.

When would you use Pointer Events instead of touch events?

Pointer Events provide a common event model for mouse, pen, and touch, while touch events are specifically designed around touch contacts and touch lists. Pointer events also expose a pointer identifier and pointer type, making shared input logic easier. I would generally choose Pointer Events for new cross-device interactions, while checking the support requirements of the product. Touch events can still matter for existing implementations or particular compatibility needs.