LayoutSize steps for fixed widths and Breakpoint caps for page maxWidth on Box, FlexBox, and Grid.
Two typed scales replace ad hoc pixel widths in product code.
LayoutSize (8–1000px)
LayoutSize members are named for their pixel width (LayoutSize.Size80, LayoutSize.Size128, …). Each maps to --size-layout-<px> in @prepared911/ui/styles.css.
The ramp uses 8px steps from 8 through 96, 16px steps from 112 through 192, then 50px steps from 200 through 1000 at a 16px root. Steps that are not on the ramp (for example 104px or 220px) have no token; pick the nearest step or use a different sizing prop.
Use on width, minWidth, height, and minHeight (and the same fields on Grid size). Do not use Breakpoint on those axes.
px
Enum
Token
8–96 (step 8)
LayoutSize.Size8 … Size96
--size-layout-8 … --size-layout-96
112–192 (step 16)
LayoutSize.Size112 … Size192
--size-layout-112 … --size-layout-192
200–1000 (step 50)
LayoutSize.Size200 … Size1000
--size-layout-200 … --size-layout-1000
1000px is the top of the layout ramp. Switchboard chrome bars at 80px min-height map to LayoutSize.Size80. For dialog-width caps near 512px, keep using InlineSize.DialogMd rather than a layout step.
Breakpoint (page caps and queries)
Breakpoint members mirror keys in breakpoints.json. Use them on maxWidth and maxHeight only (page frames, content columns, scroll hosts).
Enum
JSON key
px
Typical use
Breakpoint.CenteredBlock
centered-block
640
Settings columns, compact centered blocks
Breakpoint.Content
content
800
Primary content max width
Breakpoint.ContentLg
content-lg
960
Wider content pages
Breakpoint.Base … Breakpoint.TwoXl
base … 2xl
1080–3440
Desktop ladder (same px as container queries)
The same px values drive @media and @container rules in product CSS via breakpoints.json. Do not reuse Breakpoint.Sm (1280px) when you mean an 800px content cap.
Migration
pnpm ui:migrate rewrites exact px/rem literals on Box and FlexBox to LayoutSize or Breakpoint where the map lists them. Unlisted literals stay blocked for manual review.
Ordinal LayoutSize.Size1–Size9 members are removed. LayoutSize.Size8 and --size-layout-8 now mean 8px, not the former ordinal step 8 (600px). The codemod maps legacy ordinal uses to the nearest pixel step: Size8 → Size600, --size-layout-8 → --size-layout-600, and the listed ordinal-8 module class names (min/max inline and block, inline, block, trackMinSize8, trackMaxSize8) → their 600 forms. Other ordinals map the same way for LayoutSize.SizeN and --size-layout-N only (Size1 → Size128, …, Size9 → Size650); their module class names are not rewritten. Sites that intentionally want 8px after upgrading should use LayoutSize.Size8 / --size-layout-8 only after migrate has rewritten any legacy 600px ordinal references.
On @prepared911/ui 2.x the codemod needs to know the version you upgraded from. It reads it from git HEAD and fails closed per importer when it cannot; pass --from <pre-upgrade-semver> (for example --from 1.9.0), or --from 2.0.0 when the code was written for the pixel scale. Ordinal members are rewritten however the file reaches the enum (named, aliased or namespace imports, element access, const aliases), as are the --size-layout-N custom properties and the listed module class names; a use that cannot be rewritten safely is listed as a blocker and left as written. A write run that covers every file under a package.json with no blocked rows records prepared911.uiMigratedLayoutSize there, and later runs skip the ordinal pass for @prepared911/ui imports until --from is passed again. Legacy ui-* imports always run it.