Shift-Click Range Select in a Table — Gmail/Sheets-Style Multi-Row Selection

Most custom-built admin tables only support one selection mode: click a checkbox, one row at a time. Power users expect the selection behavior every spreadsheet and email client has trained them on for decades — plain click selects one row, Shift-click selects everything between that row and the last one clicked, and Cmd/Ctrl-click toggles a single row without disturbing the rest of the selection. This snippet implements all three modes correctly, built around the one concept that makes range selection possible: a persistent anchor.

What the anchor actually is

anchorIndex tracks the index of the last row clicked *without* the Shift modifier — not simply "the last row clicked" in general. This distinction is what makes range selection predictable: Shift-clicking always measures a range from that fixed anchor point, regardless of how many Shift-clicks happen afterward. Click row 2, Shift-click row 6 (selects 2–6), then Shift-click row 4 — the range recalculates as 2–4, not "extend from 6 to 4," because the anchor never moved during any of the Shift-click steps. This exactly matches how Sheets and Gmail behave, and is the detail most hand-rolled implementations get wrong by treating "last clicked row" and "anchor" as the same thing.

Why Shift-click replaces the selection instead of adding to it

selectRange() calls selected.clear() before filling in the new range — a fresh Shift-click always defines a brand-new contiguous selection from the anchor, discarding whatever was selected before. This mirrors real spreadsheet behavior: Shift-click is for *defining a range*, not *appending to an existing arbitrary selection* (that's what Cmd/Ctrl-click is for). Conflating the two would make it impossible to ever shrink a range back down after over-shooting it with a previous Shift-click.

Why Cmd/Ctrl-click moves the anchor, but plain click also moves it

Both the toggle path and the plain-click path update anchorIndex to the row that was just clicked — but Shift-click deliberately does not. This means a user can Cmd-click three unrelated rows, and if they then Shift-click a fourth, the range is measured from the *last Cmd-clicked row* (since that click updated the anchor), letting range and toggle selection compose naturally in the same interaction sequence, exactly as it does in real file managers and spreadsheets.

Checkboxes reflect state, they don't drive it

Every row's checkbox has tabindex="-1" and pointer-events: none in the CSS — they're rendered purely as a *visual reflection* of selected, not an independent interactive control a user could click directly. All selection logic lives in the row's own click handler, so there's exactly one source of truth for whether a row is selected, and the checkbox can never fall out of sync with the row's actual selection state.