Resizable, Draggable Floating Modal Window — Real Desktop-Style Window Behavior

Most web modals are fixed in place — centered, non-movable, non-resizable. Some tools genuinely need more: a floating panel a user can drag out of the way and resize like a real desktop window, useful for things like a notes panel, a live preview, or a debugging console that shouldn't block the content behind it. This snippet implements both drag-to-move and resize-from-any-edge using the Pointer Events API and correct edge-anchoring math.

Pointer Events with `setPointerCapture`, not `mousemove` on `document`

Both the drag and resize handlers call setPointerCapture(e.pointerId) on pointerdown, which routes all subsequent pointer events (pointermove, pointerup) to that same element even if the pointer moves outside its bounds mid-drag — a real problem with a small resize handle, since a fast mouse movement can easily outrun a 6px-wide edge strip. Without capture, moving the pointer just past the handle's edge during a fast drag would silently stop the resize; with it, the resize (or drag) keeps tracking correctly for the entire gesture no matter how far the pointer strays from the original handle.

Resizing computes new dimensions from the drag's *start* state, not incrementally

Every resize calculation is resizeState.startW + dx (or minus, depending on direction) — the delta is always measured against the position and size captured at the moment the drag *began*, never accumulated frame-by-frame from the previous frame's already-updated size. This avoids a subtle class of drift bug where small rounding or event-timing inconsistencies could compound over a long drag; because every frame recomputes from the same fixed starting snapshot, the result is always exactly consistent with how far the pointer has actually moved in total.

Why resizing from the west or north edge also moves the window's position

Dragging the *right* edge only needs to change width — the window's top-left corner stays put. But dragging the *left* edge is different: for the window to visually stay anchored at its unchanged right edge while its left edge tracks the pointer, both the width and the left position must update together, derived from the same delta. The code computes the new width first (clamped to the minimum), then sets left based on exactly how much that clamped width actually differs from the start width — not based on the raw, unclamped pointer delta — which is what keeps the window's right edge perfectly stationary even once the minimum-width clamp kicks in.

One shared resize routine for every handle

Rather than writing separate logic for each of the five resize handles (north, south, east, west, and the southeast corner), every handle shares one pointermove handler that checks which characters are present in its data-dir string ('e', 's', 'se', etc.) and applies only the relevant edge logic. The southeast corner handle needs no special-case code at all — it simply has both 'e' and 's' in its direction string, so both the east-edge and south-edge branches of the shared logic run for it automatically.