LayoutSize steps for fixed widths and Breakpoint caps for page maxWidth on Box, FlexBox, and Grid.
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 |
LayoutSize.Size80. For dialog-width caps near 512px, keep using InlineSize.DialogMd rather than a layout step.
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) |
@media and @container rules in product CSS via breakpoints.json. Do not reuse Breakpoint.Sm (1280px) when you mean an 800px content cap.
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. 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.