Layout primitives

SLASHED ships breakpoint-free, container-query-driven layout primitives in the slashed.layout layer (core/layout.css). Each is a single class with per-instance tokens you can override inline (style="--sf-stack-gap: …"). Tokens are declared in core/tokens.layout.css.

All primitives are exercised live in the demo.

The primitives

.sf-bento has two distinct, non-interchangeable modifier families — a -- (double-dash) class always modifies the container (.sf-bento itself), a - (single-dash) class targets a child placed inside it:

.sf-bento--row-tall and .sf-bento-tall are not aliases: the first stretches every row in the grid, the second stretches one grid item. Put the container modifier on .sf-bento, the child modifiers on the items inside it — never on the same element.

Size-modifier scale – xs..2xl everywhere

Every size-aware primitive supports the canonical range --xs --s --m --l --xl --2xl.

Three suffixes scale different physical dimensions. .sf-grid--xs means “narrow column tier” (denser layouts), not “small gap” — gap on .sf-grid is controlled separately by --sf-grid-gap, independent of the column-min modifier. To go beyond the built-in scale, override the scoped token directly: style="--sf-stack-gap: var(--sf-space-3xl)". The underlying space tokens (--sf-space-2xs/-3xl/-4xl) are part of the public token API.

Why no breakpoints

Primitives respond to their own container width via @container, not the viewport. Drop a .sf-grid-cols-3 inside any width context and it adapts — no media queries, no breakpoint tokens. See the container query contract for the two named containers (sf-layout, sf-alternate) and when to use them.

Composing

Primitives nest freely:

<section class="sf-section">
  <div class="sf-container">
    <div class="sf-stack">
      <h1>Title</h1>
      <div class="sf-grid sf-grid--m">
        <article class="sf-stack sf-stack--s">…</article>
        <article class="sf-stack sf-stack--s">…</article>
      </div>
    </div>
  </div>
</section>

Override a single instance without new CSS:

<div class="sf-cluster" style="--sf-cluster-gap: var(--sf-space-l)">…</div>

Responsive gaps

Gaps are already fluid: --sf-grid-gap defaults to --sf-gap, which interpolates between its mobile and desktop ends via the shared space scale. Retune the whole rhythm at once with the space-scale endpoints (--sf-space-base-min / --sf-space-base-max) rather than per-token knobs.

When one primitive needs a different gap on small vs large screens, override its scoped token inside a @container query — the same container-driven model the primitives themselves use, so the gap reacts to the same width that collapses the columns. Endpoints stay live tokens, so they still follow any scale retuning:

.product-grid { --sf-grid-gap: var(--sf-space-l); }

@container (min-width: 48rem) {
  .product-grid { --sf-grid-gap: var(--sf-space-xl); }
}

<div class="sf-container">
  <div class="sf-grid product-grid">…</div>
</div>

The override needs a container ancestor (.sf-container or .sf-cq) — the same requirement as .sf-grid-cols-*. The gap steps at the breakpoint rather than interpolating across it; for a gap that single step is imperceptible in normal use. The same pattern works for any scoped gap token (--sf-gap, --sf-content-gap, --sf-gutter, --sf-cluster-gap, …).

Container-query scope

The container-responsive primitives (.sf-grid-cols-*, .sf-bento, and any @container-scoped token override like the one above) resolve against the nearest ancestor that establishes an inline-size query container. Two wrappers establish one for you: .sf-container and .sf-content-grid — so either can host those primitives directly.

.sf-center deliberately does not. It’s a minimal centring primitive with no side effects (it doesn’t become a containing block for position: fixed descendants or a new stacking context), so it stays composable. When you need a container-responsive child inside a centred wrapper, add the query scope explicitly by composing .sf-cq:

<div class="sf-center sf-cq">
  <div class="sf-grid-cols-3">…</div>
</div>

Centring: pick the primitive, not a .center utility

Coming from a utility framework, .sf-center is a false friend. There, a .center class usually centres the content inside it (flex place-items, margin: auto, text-align). In SLASHED that job belongs to .sf-place-center; .sf-center is the Every-Layout Center primitive: a max-width, guttered wrapper that centres itself in its parent — it does not centre its own children (unless you add --intrinsic). The two are a pair: .sf-center centres itself, .sf-place-center centres its content.

.sf-place-center is the box-neutral centring primitive — display: grid; place-items: center — the named form of the community display:grid; place-items:center idiom. Reach for it when you have a plain element and just want its content centred on both axes, without adopting a row/column/wrap primitive:

<div class="sf-place-center" style="min-block-size: 12rem">
  <p>centred on both axes</p>
</div>

Otherwise centring is expressed as intent on the right primitive:

Two things to remember about .sf-center specifically:

• It centres itself, not its content. For content-centring reach for the modifiers above.
• It needs a block-level element in normal flow. margin-inline: auto doesn’t centre an inline element, and inside a flex or grid container the parent’s layout takes over the item’s sizing and alignment, so the primitive’s own width/margin model no longer drives the result. .sf-center is content-box, so --sf-center-max bounds the content and the gutter sits outside it — pick it over .sf-container when you want a typographic measure; pick .sf-container when you want an app-level wrapper that also establishes a container-query scope.