bestpractic.org
← blog
JavaScriptNovember 1, 2026 · 6 min read

You're Writing Mouse and Touch Handlers. Pointer Events Does Both.

A draggable card that works with mousedown/mousemove on desktop and breaks the moment you test it on a phone. The fix isn't a second set of touch listeners — it's deleting the mouse ones and switching to Pointer Events, which was built to handle mouse, touch, and pen as one input.

Comments
Parsa Jiravand · Frontend engineer · building bestpractic
You're Writing Mouse and Touch Handlers. Pointer Events Does Both.

The demo went great. Drag the card, it follows your cursor, drop it anywhere — smooth, on every laptop in the room. Then someone picks up their phone, drags a thumb across the card — and nothing happens. No movement, no feedback, like the card isn't even listening.

You didn't write a buggy drag handler. You wrote half of one.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
box.addEventListener('mousedown', (e) => { dragging = true; offsetX = e.clientX - box.offsetLeft; offsetY = e.clientY - box.offsetTop; }); box.addEventListener('mousemove', (e) => { if (!dragging) return; box.style.left = `${e.clientX - offsetX}px`; box.style.top = `${e.clientY - offsetY}px`; }); box.addEventListener('mouseup', () => { dragging = false; });

This is correct, tested, and works on exactly one category of device.

The instinct is to bolt on touch support: copy the three listeners, swap mouse* for touch*, convert e.clientX/e.clientY to e.touches[0].clientX/e.touches[0].clientY, and call it done.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
box.addEventListener('touchstart', (e) => { dragging = true; const t = e.touches[0]; offsetX = t.clientX - box.offsetLeft; offsetY = t.clientY - box.offsetTop; }); box.addEventListener('touchmove', (e) => { if (!dragging) return; const t = e.touches[0]; box.style.left = `${t.clientX - offsetX}px`; box.style.top = `${t.clientY - offsetY}px`; }); box.addEventListener('touchend', () => { dragging = false; });

Now it works on a phone, in isolation. But you're maintaining the same drag math twice, in two event systems that don't agree on anything — touch events report an array of active touch points (because a screen can have more than one finger on it at once), mouse events report exactly one cursor. And both paths share a bug neither the original mouse-only version nor this touch-added version ever fixed: drag fast enough, or past the edge of the box, and the "end" event stops firing, leaving the card stuck mid-drag.

That's not a mobile-only bug. It's the same bug on both input types, because mousemove and touchmove share the same design flaw.

mousemove only fires on the element it's attached to while the cursor is actually over that element — it's hit-tested live, every event. Flick the mouse fast enough, or drag past the edge of the box, and the browser stops delivering mousemove (and eventually mouseup) there at all; those events go to whatever's now under the cursor instead, which has no idea your drag was in progress. The card is left believing it's still being dragged, because the one event that was supposed to tell it otherwise was never sent to it.

Touch has a related but distinct failure mode: if the OS decides your drag gesture is actually a scroll or a browser gesture (a mid-drag notification pull-down, a back-swipe), it can cancel the touch sequence outright, firing touchcancel instead of touchend — and if you only wired a touchend listener because "that's how the drag ends," it never gets a chance to clean up.

Two input systems, two different reasons, one shared symptom: dragging gets stuck true, because neither API gives the element a reliable way to say "tell me how this interaction ends, every time, no matter what."

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

The Pointer Events API replaces mouse* and touch* with a single stream — pointerdown, pointermove, pointerup, pointercancel — that fires identically whether the input is a mouse, a finger, or a stylus. You write it once:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
box.addEventListener('pointerdown', (e) => { dragging = true; offsetX = e.clientX - box.offsetLeft; offsetY = e.clientY - box.offsetTop; box.setPointerCapture(e.pointerId); }); box.addEventListener('pointermove', (e) => { if (!dragging) return; box.style.left = `${e.clientX - offsetX}px`; box.style.top = `${e.clientY - offsetY}px`; }); function endDrag() { dragging = false; } box.addEventListener('pointerup', endDrag); box.addEventListener('pointercancel', endDrag);

Three things changed, and each one closes a specific gap the old code had:

  • One set of listeners, no branching on input type. e.clientX/e.clientY work the same for mouse, touch, and pen — no more reading e.touches[0] on one path and e.clientX directly on the other.
  • box.setPointerCapture(e.pointerId) is the actual fix for the stuck-drag bug. Once an element captures a pointer, every event for that pointer — including pointermove and pointerup — keeps firing on that element, even when the pointer moves outside its boundaries or off the page entirely. The box can't lose track of the drag because the browser is now routing events to it directly, not based on where the pointer happens to be.
  • pointercancel is the cleanup path the old code didn't have. It fires when the browser interrupts the interaction for its own reasons — a touch sequence hijacked into a system gesture, for instance. Listening for it alongside pointerup means dragging always gets reset, instead of staying stuck on true forever.

One more line matters for touch devices specifically: add touch-action: none in CSS on the draggable element.

CSS
.box { touch-action: none; }

Without it, the browser's own scroll/zoom gesture handling can still compete with your drag for the same touch input before your JavaScript gets a say. touch-action: none tells the browser "this element handles its own gestures," which is exactly what you're asking Pointer Events to do.

  • e.pointerType tells you "mouse", "touch", or "pen" when you actually need to branch — for a stylus app that wants pressure (e.pressure) and tilt (e.tiltX/e.tiltY) only from a pen, for instance. You branch when the behavior should differ, not just to read the coordinates.
  • Multi-touch stays sane. Each contact point gets its own pointerId, so a canvas handling two fingers at once tracks two independent pointer streams instead of indexing into a shifting touches array.
  • It's been safe to rely on for years. Pointer Events shipped in every major engine — Safari was the last holdout and added support in 2019 — so this isn't a progressive-enhancement decision anymore; it's the default way to handle pointing input.

Think it clicked? Take the 7-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

Pointer Events quietly fixes two separate bugs with one API. The "nothing happens on a phone" bug goes away because there's only one set of listeners to remember to wire up, not two. And the "drag freezes mid-gesture" bug — the one that was hiding in the mouse-only version from the start, then rode along into the touch-added version unchanged — goes away because setPointerCapture() finally gives the element what neither old API did: a guarantee that it keeps hearing from the pointer until the interaction is actually over.

Go find the component in your codebase with a mousedown handler and a near-identical touchstart handler sitting a few lines apart. How much of that duplication would pointerdown alone have deleted? Tell me what you find.

🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.

Thanks for reading! Let's stay connected:

? Test yourself7 questions, explained as you go ❯ Try it liveEditable playground, runs in your browser
#Javascript #Webdev #Browser #Frontend

Keep reading

Stop Calling form.submit(). Use requestSubmit() Instead.A Save button living outside the <form> tag, wired to form.submit(), looks like it works — until a blank required field sails through and the page does a full reload your fetch handler never saw coming. requestSubmit() is the method that actually clicks the button for you.6 min read Vue v-for: The Directive Unmounted Hook Bug, Fixed in 3.5.41A custom directive's unmounted hook could silently skip firing inside a keyed v-for list. The directive unmounted hook bug, Vue's real fix, and a cheat sheet.13 min read You're Debouncing Scroll Wrong. requestAnimationFrame Fixes It.Debouncing a scroll handler makes it wait until scrolling stops — which is why your sticky header always lags half a beat. requestAnimationFrame fixes the lag by syncing updates to the browser's own paint clock instead of a timer.5 min read My Reducer's Switch Stopped Being Exhaustive. `as const` Fixed It.Object and array literals widen to `string` and `number` the moment you write them, which quietly breaks discriminated unions and exhaustive switch checks. `as const` keeps the literal types — but it also freezes the value, which bites in its own way.7 min read

One post a day, in your inbox

Each one with a runnable playground and a quiz. No pitch, no digest, unsubscribe in one click.

0 comments

Sign in to join the discussion, like comments, and save articles for later.

Sign inCreate account