--- name: better-layout description: "Layout structure for web interfaces, from grouping and alignment to reading order, progressive disclosure, and adaptive breakpoints. Use when structuring a page or component, spacing or aligning controls, deciding what collapses at small sizes, handling RTL layout direction, or reviewing frontend code for layout. Triggers on layout, spacing, alignment, grouping, negative space, whitespace, visual hierarchy, reading order, progressive disclosure, breakpoints, responsive layout, container queries, safe area, full-bleed, edge-to-edge, layout margins, RTL layout, logical properties." license: MIT metadata: version: "1.0.0" --- # Layout that communicates structure Layout communicates before a single word is read: position, spacing, and alignment carry hierarchy on their own, and generous space beats decoration. A good layout also survives stress: resize it, translate it, mirror it for RTL, and it should still hold together. Apply these principles when building or reviewing UI code, and express every change in the project's existing styling system (Tailwind, plain CSS, CSS-in-JS); never introduce a second styling approach. Hit-area sizes and focus behavior are covered by the `better-accessibility` skill; visual polish (radius, shadows, animation) by the `better-ui` skill; line length and text spacing by the `better-typography` skill. Treat the numeric values below as starting points for interfaces without an established density or spacing system. Preserve deliberate platform chrome, compact professional tools, and project tokens when they remain usable under hit-area, zoom, localization, and viewport stress tests. ## Quick Reference | Category | When to Use | | --- | --- | | [Grouping & Alignment](references/grouping-and-alignment.md) | Space vs separators, alignment edges, logical properties, importance ordering | | [Spacing & Adaptivity](references/spacing-and-adaptivity.md) | Spacing between targets, layout margins, progressive disclosure, full-bleed content, breakpoints, i18n growth | ## Core Principles ### 1. Group with Space, Not Lines Negative space is the primary grouping tool; background shapes second; separator lines last, only where space alone can't carry the structure. The gap between groups must be at least 2× the gap within a group (`8px` intra-group → `16px`+ inter-group), or the grouping reads as noise. ### 2. Keep Controls Distinct from Content Interactive elements must look interactive: a background shape, a border, or a consistent placement zone. Never style a control identically to adjacent static text. ### 3. Align to Shared Edges Pick alignment edges and stick to them; every stray edge reads as noise. Use one project spacing step for each level of subordination (`16px` is a useful default). Use logical properties (`padding-inline-start`, `margin-inline-end`) for direction-dependent layout; reserve physical left/right for genuinely physical geometry. ### 4. Order by Importance The most important content sits near the top and the leading edge; reading order flows top-to-bottom, leading-to-trailing. Think in leading/trailing, not left/right. ### 5. Hint at Hidden Content Progressive disclosure needs a visible affordance. Use the project's established cue; without one, let the next item peek `16–32px` past the scroll edge or show a disclosure control. Content hidden with zero cue may as well not exist. ### 6. Breathing Room Between Targets Without an established density system, start with `12px` between adjacent bordered or filled controls and `24px` of clearance around borderless text- and icon-only controls. Compact layouts may use less when `better-accessibility` hit areas do not overlap and the controls remain visually distinct. ### 7. Inset Buttons from the Edges In content layouts, keep full-width buttons inside the layout margins (start near `16px` inline on mobile) with a visible radius. Edge-to-edge actions are acceptable when they intentionally follow established platform or application chrome, account for safe areas, and remain distinguishable from system UI. ### 8. Content Bleeds, Controls Float Backgrounds and media extend to the viewport edges; controls and text stay inside the layout margins and safe areas (`env(safe-area-inset-*)`). Sticky chrome floats above the content layer, it doesn't dam it. Sticky chrome has a keyboard cost this skill must not create and leave for someone else: a focused control that scrolls entirely underneath it is a WCAG 2.2 SC 2.4.11 failure. Partial obscuration is permitted; author-created content must never completely hide the focused component. Whenever you add fixed or sticky chrome, set `scroll-padding-block` on the scroll container to at least its height so focus never lands fully under it. The requirement itself belongs to `better-accessibility`; reserving the space is layout's job. ### 9. Hold Structure Until It Breaks Breakpoints come from the content, not device presets. Keep the expanded layout as long as it genuinely fits and collapse late; prefer container queries for component-level adaptation. Test the smallest and largest sizes first. ### 10. Plan for Growth and Clipping Plan for substantial and language-dependent string growth rather than relying on a universal percentage: no fixed widths or heights on text containers, and let rows wrap. Never park critical actions where resizing or scrolling clips them; keep them reachable in the normal flow or stable chrome appropriate to the product. ### 11. Let Flex and Grid Children Shrink A flex or grid item's default minimum size is its content, not zero — so a long unbroken string, a wide table, or a `
` block pushes its parent wider instead of wrapping or truncating, and the overflow surfaces somewhere else entirely. Set `min-inline-size: 0` (or `min-width: 0`) on the shrinking child. A flex item that is a scroll container (`overflow: scroll`, `auto`, `hidden`) also zeroes that automatic minimum — `overflow: clip` is non-scrollable and does not — but scrolling clips the content and establishes a new formatting context, so reach for the explicit `min-inline-size: 0` unless you actually wanted those.

This is the mechanical cause of most "the layout blows out at narrow widths" bugs, and of truncation that silently does nothing: `text-overflow: ellipsis` cannot engage on a child that never gets smaller than its content. Truncation mechanics belong to `better-typography`; making room for them is this skill's job.

Grid has a second form of the same trap: `1fr` means `minmax(auto, 1fr)`, so a `1fr` column will not shrink below its content either. Use `minmax(0, 1fr)` when the column holds text that must wrap or clip.

### 12. Use Dynamic Viewport Units for Full-Height Regions

`100vh` is the *largest* viewport height, so on mobile it includes the space under browser chrome that retracts on scroll — a `100vh` hero is taller than the visible viewport and its bottom content sits under the URL bar. Use `100dvh` for a region that should track the visible viewport as chrome shows and hides, `100svh` when it must fit the smallest state without ever being clipped, and `100lvh` only when you deliberately want the largest.

The units are widely available (Chrome 108, Firefox 101, Safari 15.4). Prefer `min-block-size` over a fixed height so content taller than the viewport still scrolls.

## Common Mistakes

| Mistake | Fix |
| --- | --- |
| Separator line where spacing would do | Remove the line, double the gap between groups |
| `margin-left` / `padding-right` in a localizable layout | `margin-inline-start` / `padding-inline-end` |
| Content-layout button accidentally touches the viewport | Inset within the project margins; preserve intentional platform chrome |
| Carousel/scroller that looks complete | Let the next item peek `16–32px` past the edge |
| Long string or wide table blows out the layout | `min-inline-size: 0` on the flex child, or `minmax(0, 1fr)` on the grid column |
| `text-overflow: ellipsis` has no effect | The child never shrinks below its content; give it `min-inline-size: 0` |
| `100vh` region taller than the visible viewport on mobile | `100dvh` to track visible chrome, `100svh` to never clip |
| Adjacent controls merge or expanded hit areas overlap | Increase the gap using the project scale; use `12px`/`24px` as starting points |
| Breakpoints at 768/1024 because they're the defaults | Break where the content actually stops fitting |
| Fixed-width text container sized to one language | `max-width` + wrapping; test pseudo-localization and representative locales |
| Primary action at the clip-prone bottom of a pane | Sticky positioning or stable chrome with safe-area padding |

## Severity

- `HIGH` blocks content or an action at a supported viewport.
- `MEDIUM` harms hierarchy, reading order, or adaptability.
- `LOW` is isolated alignment or spacing polish.

## Review Output Format

Use this format only when the user asks for a standalone layout review. When `better-interface` orchestrates the review, provide domain evidence and findings to that skill and let its output format, severity scale, consolidation rules, cap, and verdict take precedence.

Present the standalone review in two parts.

### Findings

Group all confirmed findings by principle. Use a markdown table with **Severity**, **Location**, **Before**, **After**, and **Why** columns. Never use separate "Before:" / "After:" lines.

- **Location**: cite `path/to/file:line`. If the artifact has no source files, cite the exact screen and component instead.
- **Before / After**: show the current layout and an actionable replacement.
- **Why**: name the violated principle and its effect on comprehension or adaptability.

Consolidate a repeated systemic issue into one row and list every affected location. Omit principles with no findings.

### Example

#### Group with space, not lines

| Severity | Location | Before | After | Why |
| --- | --- | --- | --- | --- |
| LOW | `src/Settings.tsx:41` | `border-b` on every settings row | Remove borders; use `space-y-2` within groups and `space-y-8` between groups | Spacing communicates grouping with less visual noise |
| LOW | `src/ProfileForm.tsx:58` | `
` between form sections | Replace with `mt-10` on each section heading | Section hierarchy should not depend on repeated rules |

#### Align to shared edges

| Severity | Location | Before | After | Why |
| --- | --- | --- | --- | --- |
| LOW | `src/Card.tsx:24` | Card text at `pl-4`, card icon at `pl-3` | Align both to the same `pl-4` edge | Shared edges create a legible structure |
| MEDIUM | `src/Nav.css:19` | `margin-left: 16px` | `margin-inline-start: 16px` | Physical properties break direction-aware layouts |

### Verification and Verdict

After the findings:

1. **Verification**: list the exact checks run and their observed results across the relevant viewport widths, reading order, zoom, and RTL state. If a check was not run, state what still needs verification.
2. **Verdict**: `Block` if any `HIGH` finding remains, `Needs changes` if only `MEDIUM` or `LOW` findings remain, and `Approve` only when no actionable findings remain.

When there are no findings, omit the tables, state "No actionable layout findings", report verification, and end with `Approve`.