Spacing
The spacing scale and layout primitives used throughout the design system.
Page max-width
Matches the main app's page container: max-w-6xl for general pages, max-w-5xl for data-dense pages (wide tables, dense grids). This docs site applies max-w-6xl to every page via the shared layout.
Control height scale
Every standalone field- or button-like control shares one height per size step, so any two of them sit flush when placed in the same row (a filter bar, a table footer, a page header next to a tab strip). The shared box model: the same vertical padding at each size, plus a 1px border on every variant — real where the control already has one (Select, Combobox, Input, Outline), transparent where it doesn't (Primary, Secondary, Ghost, Destructive, Link, Tabs). A transparent border still reserves the same box-model space as a real one, so height matches without changing how the control looks.
| Size | Padding (y) | Border | Applies to |
|---|---|---|---|
| xs | 4px (py-1) | 1px, real or transparent | Button, IconButton, Select, Combobox, Tabs |
| sm | 6px (py-1.5) | 1px, real or transparent | Button, IconButton, Select, Combobox, Input, Tabs |
| md | 6px (py-1.5) | 1px, real or transparent | Button, IconButton, Select, Combobox, Input, Tabs |
Exempt by design: Plain (Button/ IconButton's inline, zero-padding variant) and Textarea (multi-line, grows with content) — neither is meant to sit at a fixed height next to these controls.
For new components: don't invent a new per-size padding scale for a field- or button-like control — reuse the padding values above, and add a border (transparent if the variant has no visible stroke) rather than leaving it off. This is a candidate for a future lint rule: any component in this scale whose padding or border doesn't match the table should fail.