Spacing

The Orbit spacing scale is built on a base of 4px. Every token is a multiple of 4, which means components designed to these values automatically align to a 4px grid. This makes spacing decisions predictable — when you pick a token, you're choosing a position on a shared scale rather than an arbitrary pixel value.

Semantic spacing tokens map a primitive scale step to an intended role — component-level padding and gaps, or page-level layout rhythm. Use these over primitive tokens directly wherever a component or layout role applies; they carry intent and stay in sync if the underlying scale step changes.

Token names follow the pattern --op-space-[step], where the step number corresponds to the rem value × 4. For example, --op-space-16 is 1rem (16px), and --op-space-32 is 2rem (32px). Note that the scale skips steps 7, 9, 11, and others — only the steps with established usage in the system are included.

Match the token to the relationship

Spacing communicates the relationship between elements — close elements feel related, distant elements feel separate. Use smaller tokens for elements within the same component (space-1 through space-4) and larger tokens for gaps between components or sections (space-6 and above).

Use tokens, not raw values

Never use a raw pixel or rem value in component styles. Even if the value happens to match a token — write var(--op-space-16), not 16px. Raw values break the grid when the scale is updated, and they're invisible to tooling that audits token usage.

Vertical vs horizontal spacing

Vertical spacing (between sections, stacked cards, form fields) typically uses larger values than horizontal spacing within the same context. A form where fields have 24px vertical gaps (space-6) and 16px horizontal padding (space-4) feels right. Reversing those values makes the layout feel compressed.

Consistent padding within a component

Use the same token for the horizontal and vertical padding of a component wherever possible. If a card uses --op-space-24 on all sides, it feels balanced. If it uses different values on each side without a clear reason, it reads as a mistake rather than a deliberate design decision.

Every interactive element must have a minimum touch target of 44×44px, following WCAG 2.5.5 (AAA) and Apple and Google platform guidelines. This applies to buttons, links, checkboxes, radio buttons, switches, and all other interactive controls.

When a component's visible size is smaller than 44px, add invisible padding or use an absolutely-positioned overlay to extend the tap area without changing the visual layout. Never reduce the touch target to match a small visual design — adjust the visual design or add the invisible zone.

Component	Visible size	Touch target	Approach
Button (medium)	40px height	44×44px	Add 2px invisible vertical extension
Button (small)	32px height	44×44px	Add 6px invisible vertical extension
Checkbox / Radio	16–20px	44×44px	Extend target to the label; label is part of the touch area
Icon button	24–32px	44×44px	Add invisible padding via min-width/min-height: 44px
Link (inline text)	Line height	44px height preferred	Increase line height or use block-level link where possible

On Social Point community-facing surfaces — where users include people with motor impairments, older devices, and touch-only navigation — treat 44×44px as a strict minimum and aim for 48×48px where the layout allows.