If a core interaction hides behind a modifier key, it doesn't exist

TLDR

Users do not discover modifier-gated gestures. If your canvas app's marquee selection requires Ctrl+drag while plain drag pans, you have effectively shipped no marquee selection: the feature exists in the code and not in the product. Plain drag should do the thing users try first, and the thing they try first is selection.

The position

The default gesture budget of a canvas is tiny: plain drag on empty space, plain drag on an object, click, double-click. Whatever you bind to those four is your product. Everything behind a modifier key is documentation-dependent, and nobody reads canvas documentation. So the defaults must go to the highest-frequency intents, and in an editor (as opposed to a map), the highest-frequency empty-space intent is "select these things," not "move the camera."

What a lot of tools do, and why

Map-style apps (Google Maps, PDF viewers, image viewers) bind plain drag to pan, because their content is read-only and navigation is the only intent. Early-generation diagram tools inherited that binding because they started life as viewers, then bolted selection onto a modifier: Ctrl+drag, or a dedicated "selection mode" toolbar toggle.

Our editor did exactly this. Plain drag panned. Marquee lived behind Ctrl+drag. It shipped that way because pan came first chronologically and selection had to fit into whatever gesture space was left.

Why it fails for editors

Watch anyone open an editing canvas for the first time: they drag on empty space to lasso things. Every mainstream editing surface (Figma, Excalidraw, draw.io, every OS file manager, every slide tool) taught them that. When the canvas pans instead, they conclude multi-select does not exist, and they fall back to shift-clicking items one at a time, forever. We had the feature; support conversations proved users did not know.

There is also an asymmetry argument. Panning has good alternatives that users already know: scroll wheel, trackpad two-finger scroll, Space+drag, middle-mouse drag. Marquee selection has no alternative idiom. Giving the scarce default gesture to the intent with five substitutes, while the intent with zero substitutes hides behind a modifier, is exactly backwards.

The better allocation

Plain drag on empty canvas: marquee. Space+drag or middle-mouse: pan. Keep the old modifier binding as an alias so existing muscle memory still works. That is the entire change; ours was a three-line condition edit plus a guard in the pan handler:

// before: marquee only with modifier
if (isBackground && (e.ctrlKey || e.metaKey)) startMarquee(e);
// after: marquee by default, pan moves to Space/middle if (isBackground && e.button === 0 && !spaceHeld) startMarquee(e);

What you give up

Users coming from viewer-style tools will drag expecting pan and get a selection box. That mismatch is real but cheap: a selection box that appears and disappears costs nothing and teaches the binding instantly, whereas the reverse mismatch (expecting selection, getting camera movement) scrolls the user away from their content and teaches them the feature is missing. Also, touch devices need care: one-finger drag as marquee fights one-finger pan conventions, so touch keeps its own gesture map.

When modifier-first is right

If your surface is genuinely navigation-dominant (a map, a read-only graph explorer, a zoomed image), plain-drag pan is correct and selection is the rare intent that can pay the modifier tax. The rule is not "marquee always wins." The rule is: rank intents by frequency for your surface, hand the four default gestures to the top four, and let modifiers carry the tail. If you find a core intent living behind Ctrl, you have the ranking wrong.