Intersection and containment selection yield different results

What it is

Intersection selection includes any object overlapping a marquee; containment selection includes only objects whose entire boundary lies inside it. They give different results for boundary-crossing objects, and the choice must be a predictable selection semantic, not an implementation accident.

Why it happens

Intersection reduces the spatial precision needed to capture a target, suiting lines, nodes, and sparse small objects. Containment demands a more precise box but avoids sweeping in neighbours at its edge. Object bounds, visible paths, transparency, and group hierarchy decide which geometry actually counts as overlapping or contained.

The two rules encode different assumptions about why someone drew the box in the first place. Intersection assumes the person is marking a region within which relevant things exist, and tolerates an imprecise boundary — this is why line-connection tools and CAD snap workflows favour intersection: dragging a box usually means "roughly this area," not "avoid the neighbour half a pixel outside." Containment assumes a strict ownership expectation for "selected" — better to miss an object than to accidentally grab one just outside the box — which is why graphics editors use containment before a bulk move or delete, specifically to protect nearby elements nobody intended to touch. Some systems go further and encode direction into the rule itself: dragging left-to-right yields containment, right-to-left yields intersection (early Windows Explorer and AutoCAD's window/crossing selection work this way), turning "which rule applies" from a setting into part of the gesture. The cost is that this semantics is invisible and easy to forget.

Studying it

Across density, size variation, spacing, and marquee direction, measure accidental inclusion, omission, redraws, and completion time. Include lines, partial occlusion, and grouped objects — uniform rectangular icons understate the difference between the two geometric rules. When comparing a direction-encoded rule against a single fixed rule, measure the added cognitive load — whether people can recall which direction maps to which rule — separately from raw selection accuracy.

Where it stops holding

Neither rule is universally correct: graphics editors often need containment to avoid sweeping in neighbours, while maps and relationship diagrams may favour intersection. Direction-dependent rules can help efficiency, but without prominent feedback — such as the marquee's stroke style changing with direction — people cannot recall that a reversed drag changes the outcome and will treat it as random. Multi-select modifiers add a further layer: holding a modifier while marqueeing stacks an "add" or "invert" operation on top of whichever geometric rule applies, and when three layers of rule are active at once, each needs visible feedback or the resulting selection becomes impossible to reverse-engineer.

Applying it

• Choose one default geometry aligned with the task, and preview the objects that will be selected live during the drag rather than revealing the result only on release.
• If both rules exist, use a clear, stable modifier or direction convention, and change the marquee's visual style (solid vs. dashed stroke) with whichever rule is currently active.
• How to check: build a boundary-object regression set — deliberately place objects whose bounds cross common marquee paths — and verify that the selection result, the live preview, and the documentation stay consistent.

Related

• Same group: C1.09.1 Marquee selection must start in empty space or it conflicts with object dragging · C1.09.3 Marquee selection and canvas pan need modes or modifiers when sharing empty space
• Nearby: C1.05 Cursor hotspots and hit testing · C1.08 Drag and drop
• Search terms: intersection selection · containment selection · directional marquee