Pointer Gesture, Touch Action, and Alternate Control

Working case

A reviewer orders three evidence cards in case 47. Dragging a card on a small phone can conflict with vertical page scrolling. The interface offers Move up and Move down buttons on each card, then adds drag as an optional shortcut for devices where it is usable. The buttons update order and announce the result; the drag path uses the same reorder operation. Only the drag handle restricts touch gestures, and the rest of the card remains scrollable. If the pointer is canceled by a browser gesture, the preview resets without saving a half-complete order.

Implementation boundary

Keep committed order separate from a temporary drag preview. On pointerdown, record the original order and capture the pointer only when a drag actually begins. On pointerup, validate the target position and commit through the same server mutation as button controls. On pointercancel, Escape, or route leave, restore the original view. Do not use a gesture as a hidden authorization route: the server validates the requested position and current record version. Consider touch target size, zoom, reduced motion, and a text announcement of the new position.

function moveEvidence(evidenceIds, fromIndex, toIndex) {
  const reorderedIds = [...evidenceIds];
  const [movedId] = reorderedIds.splice(fromIndex, 1);
  reorderedIds.splice(toIndex, 0, movedId);
  return reorderedIds;
}
console.log(moveEvidence([47, 62, 89], 2, 1).join(","));
// Output: 47,89,62

Cost and tradeoffs

A reorder in an array of n cards can cost O(n) to create the new order, while each pointermove should avoid expensive full-list work. Coalesce visual updates in animation frames and do not write to the server on every movement. Restricting touch-action on a narrow handle preserves page panning elsewhere, though it may make the drag target smaller. Measure accidental drags, canceled gestures, keyboard completion, and movement latency. The simpler button path is also an important recovery mechanism after a drag fails.

Failure trace

A developer sets touch-action none on the entire feed to make drag smooth. Users can no longer pan normally over card content, and some zoom workflows suffer. Restrict the declaration to a deliberate handle or remove drag. Another defect commits a preview when pointercancel fires during a scroll. Treat cancellation as rollback. Test mouse, touch, pen, keyboard, switch-style sequential focus, browser zoom, and an interrupted gesture. Confirm that both drag and buttons produce the same validated final order.

Decision note

Preserve native page movement and provide an equivalent discrete control. A gesture is useful only when its cancellation and accessibility paths are as clear as its happy path.

Verification

• Complete the primary case with the capability available and with it denied or absent.
• Interrupt the interaction during its pending state and confirm no stale resource, focus, or scroll state remains.
• Check that server authorization and validation still hold after the browser interaction.

Common Mistakes

• Disabling touch panning over an entire content region.
• Saving a partial order after pointercancel.
• Making drag the only way to reorder.

Connected lessons

Overlays, Scroll, and Mobile Viewport; Stacking Context, Top Layer, and Overlay Contract; Scroll Containers, Anchoring, and Chaining; Visual Viewport, Keyboard, and Focused Input; Complex Accessible Interactions; Data Table Versus Interactive Grid; Responsive interaction: preserve content and control order.

Apply and check

Build Project: mobile review overlay and scroll and review Web Development: browser capability and viewport decisions quiz.

Further connections

SVG, Canvas, Scene Model, and Hit Testing.