Desktop UI Spacing Sizing

Sizing, Spacing & Overflow (Desktop)

Sizing caps

Every dimension that can grow unbounded should have a stated cap, decided deliberately rather than left to accident:

• Line length: cap body text at roughly 60–80 characters per line even in a wide pane — text stretching across a maximized ultrawide window becomes hard to track line-to-line. Use a max-width on the text container, not the whole layout.
• Content column max-width: for single-column content areas (settings pages, detail views), cap around 720–840px and let extra window width become margin, not stretched content.
• Component size caps: modals, dropdowns, and cards should all have a stated max-width/height (see desktop-ui-surfaces-overlays) — "however big the content makes it" is not a size decision.
• Density modes: if the app serves both casual and power users, consider a comfortable/compact density toggle (row height, padding) rather than picking one density for everyone — but don't build this unless there's a real need; it's easy to over-engineer.

Empty (negative) space

Negative space is a tool for creating hierarchy and rhythm, not a default to maximize everywhere:

• Group related elements with less space between them, and separate unrelated groups with more — the size of the gap should communicate relatedness. This is often called proximity, and it's doing more hierarchy work in a dense app than font-weight alone.
• Don't pad content out with empty space just to "look clean" if the result is a screen that could show 3x the useful information in the same space — desktop users often want density (see the anti-slop "fake centering" tell in foundations). A sparse settings page with one option per screen-height is a red flag, not minimalism.
• Conversely, don't cram controls edge-to-edge with no breathing room — the fix for "too sparse" is never "zero space," it's "space that matches the content's actual grouping."

Overflow limits & dynamism

Decide, explicitly, what happens when content exceeds its container — never leave this to whatever the framework does by default:

Responsive behavior at real window sizes

A desktop window is resized far more often than a phone screen changes orientation, and it happens during use, not just at load:

• Test every layout at the app's defined minimum window size (see desktop-ui-layout-navigation), not just a comfortable default size.
• When space gets tight, prefer this order of degradation: collapse secondary panels → shrink non-essential padding → hide (not truncate into illegibility) the lowest-priority controls behind an overflow menu → only as a last resort, truncate text.
• Never let a resize operation cause a layout reflow that's visually jarring (content jumping, reflowing repeatedly mid-drag) — debounce expensive relayout work during an active resize if needed, and settle on the final layout once the drag ends.

Accessibility & internationalization

• On any device where touch is a plausible input (touchscreen laptops, 2-in-1s), give interactive targets a minimum 24×24px hit area even when the visible control is smaller — pad the hit area invisibly rather than enlarging the artwork itself. See desktop-ui-accessibility-i18n.
• Size labels for translated text, not the English string — German and Finnish commonly run 30–40% longer, and a layout with zero headroom is the first thing to break in translation.

Review format