Idea
A named "boxed" section layout primitive — content inset within visible edges (border/shadow/rounded corners framing the section) — as the logical counterpart to the existing .sf-full-bleed / .sf-breakout primitives in core/layout.css.
Why
We already have the "break out of the container" end of the spectrum; we don't have a named pattern for the opposite: a section deliberately framed/inset rather than edge-to-edge. Right now a user has to hand-roll this with raw border/shadow/radius tokens instead of reaching for one documented primitive.
Scope
- Design as a macro (
.sf-boxed or similar) built from existing tokens (--sf-radius-*, --sf-border-*, --sf-shadow-*, --sf-gutter) rather than introducing new token groups.
- Should compose with the existing
.sf-content-grid/.sf-container system, not duplicate it.
- Update
docs/layout.md and docs/llm-guide.md if shipped as a PUBLIC macro.
Idea
A named "boxed" section layout primitive — content inset within visible edges (border/shadow/rounded corners framing the section) — as the logical counterpart to the existing
.sf-full-bleed/.sf-breakoutprimitives incore/layout.css.Why
We already have the "break out of the container" end of the spectrum; we don't have a named pattern for the opposite: a section deliberately framed/inset rather than edge-to-edge. Right now a user has to hand-roll this with raw border/shadow/radius tokens instead of reaching for one documented primitive.
Scope
.sf-boxedor similar) built from existing tokens (--sf-radius-*,--sf-border-*,--sf-shadow-*,--sf-gutter) rather than introducing new token groups..sf-content-grid/.sf-containersystem, not duplicate it.docs/layout.mdanddocs/llm-guide.mdif shipped as a PUBLIC macro.