Drag to Reorder Table Rows — HTML5 Drag and Drop Table

Ordered lists — a sprint backlog, a priority queue, a playlist — are far easier to reorganize by dragging a row where it belongs than by editing a rank number in a text field. This snippet implements genuine HTML5 drag-and-drop for table rows: real draggable="true" elements, dragstart/dragover/drop handlers, and a live drop-indicator line that shows exactly where the row will land before you release the mouse — not a fake reorder that just swaps two rows on click.

Native drag events, not mouse-position simulation

Every <tr> is marked draggable="true". On dragstart, the handler records which row index is being dragged (dragIndex), adds a .dragging class that fades the row to signal it's lifted, and calls e.dataTransfer.setData(...) — required by the drag-and-drop spec for some browsers to permit the drag at all, even though this implementation tracks the source index in a JS variable rather than reading it back out of dataTransfer.

dragover must call preventDefault, or drop never fires

By default, browsers don't allow dropping onto arbitrary elements — a drop event only fires on a target if its dragover handler called e.preventDefault(). This is the single most common HTML5 drag-and-drop bug: skip that line and the whole interaction silently does nothing. Here, every dragover on the tbody prevents the default and sets dropEffect = 'move' so the cursor shows the correct move icon.

A drop-indicator line computed from real cursor position

Rather than just highlighting the whole row you're hovering, dragover computes the cursor's vertical position relative to the hovered row's getBoundingClientRect() — if the cursor is in the top half, the indicator line is inserted above that row; in the bottom half, below it. This is a genuine positional calculation on every dragover event, not a static highlight, and it's what makes the drop location obvious before you let go.

Correct index math on drop

The trickiest part of any row-reorder is getting the final index right when the dragged row itself is removed from the array before being reinserted — removing an earlier row shifts every later index down by one. The drop handler splices the dragged item out first, then decrements insertAt by one if the target position was after the original position, before splicing it back in at the corrected index — the standard off-by-one trap in drag-reorder logic, handled explicitly here rather than by luck.

A real array as the source of truth

The whole table re-renders from the ITEMS array after every successful drop, so the DOM never drifts out of sync with the underlying order — dragging doesn't directly move DOM nodes around, it reorders the array and lets render() rebuild the table, keeping row numbering and any derived values consistent.

Customizing it

Persist the new order to a backend on drop, add multi-row drag selection, or combine with a column drag reorder for both axes. Compare with an editable table for inline field edits alongside reordering.