Responsive layout

Start with the smallest useful layout

Write the single-column or wrapped layout first. Add a breakpoint only when the content becomes hard to scan, labels collide, or an action loses enough room to remain useful. Device names do not determine that point; the content does.

Choose measure before a breakpoint

Use a measure when one region needs a readable or predictable inline size. Use a container query when a reusable region should respond to its own available space. Use a viewport breakpoint when the page shell or several regions must reflow together.

<article className="max-w-tinyrack-measure-xl">...</article>
<section className="@container"><div className="grid @md:grid-cols-2">...</div></section>

Use the shared breakpoint scale

Tinyrack publishes --breakpoint-sm, --breakpoint-md, and --breakpoint-lg as Tailwind theme variables. TypeScript exposes the same values as tinyrackBreakpoints. They do not create CSS custom media rules.

Reflow, do not just shrink

• Stack a label and value before either becomes cramped.
• Wrap an action row while keeping the primary action reachable.
• Move secondary navigation behind an explicit control instead of hiding it.
• Let tables scroll inside their own container when columns must stay comparable.

<section className="grid gap-4 md:grid-cols-[minmax(0,1fr)_auto]">
  <div>Rack details</div><div className="flex flex-wrap gap-2">Actions</div>
</section>

Divide implementation responsibilities

Use CSS or Tailwind for visual reflow and container queries. Read tinyrackBreakpoints in TypeScript only when behavior, data loading, or interaction mode must change. Import @tinyrack/ui/core.css before component styles so Tailwind resolves the shared --breakpoint-* scale.

Responsive QA

Check immediately below, at, and above every changed threshold. Include a 390px viewport, 200% zoom, long localized labels, keyboard focus order, locally scrolling tables, and confirmation that no essential action disappears.