Drag-and-drop is not one interaction.

The instinct is to reach for mousedown, mousemove, mouseup. They're old, they're everywhere, every tutorial uses them. They're also wrong for drag.

Two failure modes show up immediately. The first: mouse events don't fire on touch devices. The second, less obvious: if the user drags the pointer outside the window — over a different app, off the screen — mouse events stop firing entirely. Your element is now stuck mid-drag with no way to recover.

Pointer Events fix both. One unified surface for mouse, touch, and pen, plus setPointerCapture which routes every event back to the original target until the pointer is released. Try it.

Two thresholds gate the start of a drag: distance (pointer must move at least N pixels) and time (pointer must be held at least M milliseconds). They exist because the alternative — drag fires on pointerdown — destroys two interactions: click, and text selection.

Different products tune these for different jobs. A list app like Linear uses a small distance and zero hold — you want responsiveness because accidental clicks on a row are cheap. A canvas tool like Figma is similar. A mobile-first reorder uses a long hold because there's no other way to disambiguate scroll from drag.

Both gestures begin identically — pointerdown, then movement. The browser cannot know which is intended until the app declares its preference. By default it treats press-and-move as text selection. The drag only wins if you explicitly take the gesture away from the browser.

Two mechanisms do that. setPointerCapture, called on pointerdown, hands the entire gesture to your element — every subsequent move and release event routes there, and the browser stops doing anything else with the pointer. That alone ends the selection conflict. user-select: none is the belt-and-suspenders backup: even if capture ever fails or is released early, CSS instructs the browser that this element's text is not selectable at all. touch-action: none does the equivalent on touch, preventing the browser from interpreting a slow press-and-move as scroll.

The demo below makes this visible. The broken list has a drag handler but skips setPointerCapture and user-select: none. It uses a 50 px threshold — generous enough to give you time to see what happens in the gap: the browser runs its text-selection logic and starts highlighting. The drag only kicks in after you've already lost the gesture. The correct list calls setPointerCapture immediately on pointerdown, closing the window before the browser can compete. Threshold is 4 px and drag starts at the first meaningful movement.

What the user sees as "the thing I'm dragging" is a visual proxy. The original row might stay put (in a portal strategy), might move with the pointer (in an in-place strategy), or might be invisible while the browser draws its own ghost (in a native strategy).

Each choice locks in trade-offs. Get this one wrong and you spend the rest of the project fighting bounding-box math or jank.

Three ways to answer it. document.elementFromPoint(x, y) asks the browser — which is correct, handles overlapping z-indexes, but triggers a layout flush every call. Bounding-box intersection scans an array of cached rects — O(n) per frame, but no layout. A spatial index (R-tree, quadtree) is O(log n), worth it past a few hundred targets.

The right choice depends on your worst case. A reorderable list of ten items? Use whatever. A Figma canvas with eight thousand objects? You're maintaining a quadtree whether you like it or not.

List reorder is mostly a single line of math. If the pointer's Y is above the midpoint of the hovered row, insert before. Otherwise, insert after. Treating the row itself as the drop target — instead of its top or bottom half — is the bug that makes lists feel sticky and wrong.

Canvas drop is even simpler in theory and harder in feel. The placed position is (pointer − cursorOffset), where cursorOffset is the distance from the object's top-left to where you grabbed it. Forget the offset, and dropped objects jump to the cursor — every Figma user has felt the difference in a worse tool.

Keyboard reorder is the original sin. The pattern is Space to pick up, arrows to move, Space to drop, Escape to cancel — set by react-beautiful-dnd in 2017 and adopted by every serious app since. It works because it maps the four mental moments of a drag to four keystrokes, and announces every state change to screen readers via aria-live.

The other three: long-press on touch (otherwise scroll wins), prefers-reduced-motion (skip the inertia and ease curves), and a visible focus ring on the picked-up state so keyboard users can tell something has happened.

When you drag a file from the OS into a browser tab, the browser never receives pointer events — it gets OS-level drag events. The only API that can hear them is the HTML5 Drag and Drop API: dragenter, dragover, dragleave, drop.

This is the one place in this piece where we endorse it. You have no choice — the OS controls the gesture, Pointer Events are completely silent. event.dataTransfer.files gives you the dropped files on the drop event.

Two non-obvious rules govern cross-app drop. First, you must call e.preventDefault() on every dragover event — without it, the browser treats the drop as a navigation (opens the file) and your handler never fires. Second, dragleave is treacherous: it fires whenever the pointer moves over a child element, which makes the drop zone appear to flicker off. The standard fix is a drag-entry counter that increments on dragenter and decrements on dragleave.

This is also the foundation of every upload UI you've used — Figma's import, Notion's file attachment, GitHub's drag-to-attach. They're all the same four event listeners, roughly 20 lines of code. The quality difference between them comes entirely from the drop zone feedback: how quickly it activates, whether it handles multiple files, what it does when you drop something it can't use.