Responsive layouts

Why this matters

Responsive design is not making the desktop composition narrower. It is deciding what relationships should survive as available space changes. A crew member checking tomorrow's assignment on a phone needs the same certainty as a dispatcher on a wide monitor — different arrangement, same task completed.

What to understand

Start with the smallest screen you support and the full main task. Widen until a second column or a persistent navigation region earns its place. That content pressure justifies your breakpoints better than device names alone. For each breakpoint, say what moves: a rail drops below content, a toolbar wraps into groups, navigation becomes a drawer, a table gets its own sideways scroll.

When this doesn't apply

A sidebar does not automatically need to become a drawer at lg. A table does not automatically need cards on mobile — sideways scrolling keeps comparison intact, while a stacked record layout suits reading one item at a time. Auto-stacking every cell can destroy the relationships the task depends on.

In practice

.results {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr)); 
  gap: 1.5rem;
}

.result {
  min-width: 0;
  overflow-wrap: anywhere;
}

Here a card may shrink below 18rem when its container is narrow. This suits independent items — it doesn't decide whether a card grid is the right way to compare. Use page-wide queries for page-wide changes; container queries let one reusable piece adapt to its own space. Ask your agent to check current container-query support and syntax for the browsers you support.

Preserve meaning when space runs out: let labels wrap when the words matter, never use fixed-height boxes that cut off enlarged text, and use min-width: 0 or minmax(0, 1fr) where content must shrink inside its row or grid. Break long unbreakable values on purpose; keep code and comparison data in their own scroll regions when needed. Never hide key actions or columns without another good way to reach them, and keep what you see in the same order as keyboard focus moves.

Include input and viewport changes: never require hover, keep main touch targets comfortable, and offer an alternative whenever something needs dragging. Test the on-screen keyboard around forms, sticky buttons, and full-height layouts — dvh, svh, and lvh handle the phone's appearing browser chrome differently, so ask your agent to pick the one matching whether the region should resize.

Related skills

Use $layout for structural problems. Use $craft when composition and visual hierarchy are also changing. Continue with accessibility.