Skip to content
GitHub
Sections

Reference · Components and layout

Layout method

This is a spec: descriptive guidance, not a checkable rule. It carries no forbidden and instead pair, and no jig check detector applies to it directly.

The spec

Not a component. The procedure for structuring any screen, before styling anything.

Step 1: Group

Four tools, weakest to strongest. Use the weakest that works (A-67):

ToolPrincipleCost
Continuity — aligned in a lineThe eye follows a continuous lineFree
Similarity — same size, shape, colourAlike things are read as relatedFree
Proximity — closer together than to anything elseNear things are read as relatedSpace
Common region — a shared containerStrongest cue, and the heaviestClutter

Combine them and the container usually becomes unnecessary — a table's rows are already aligned, alike and close. Break continuity deliberately to mark the end of a group, or to interrupt a list with something that is not part of it.

Step 2: Order by importance

Six variables carry hierarchy: size, colour, contrast, spacing, position, depth. The procedure:

  1. 1.
    Group related information into sections.
  2. 2.
    Order the *sections* by importance; important ones first.
  3. 3.
    Within each section, style each element by its importance — larger, higher contrast, more surrounding space, elevated.

Position does more than it looks: people best recall the first and last items in a sequence, so a price placed last, beside the primary action, is the one remembered.

Give elements *similar* prominence where they should be read as a pair — matching a label's weight to its icon's balances them instead of letting one shout.

Step 3: Space from the inside out

Start at XS on the innermost rectangle and step up moving outward (D-69). Between two options, take the larger.

Step 4: Align to a grid

Main containers align to a 12-column grid; small elements *inside* them do not — those use the spacing options.

  • Columns flexible (percentage), 12 on desktop dropping to 4 on mobile.
  • Gutters fixed, narrower than columns, and kept empty. --grid-gutter.
  • Margins keep content off the screen edge, wider on large screens. --grid-margin.

Step 5: The squint test

Blur the design, zoom out, or step back. You should still be able to tell what the screen is for and which element matters most. If everything reads at one weight the hierarchy has failed; if elements smear together the white space is too tight.

When the page can be rendered, test it without colour. Render it with filter: grayscale(1) on the root element — in a browser tool, one line of script — and look again at every size. Spacing, contrast and size should carry the order on their own: the primary action still reads first, the heading still leads its section, what belongs together still sits together. Colour is added on top of a hierarchy that already works; it does not make one. If the primary action is only findable by its hue, the hierarchy is too weak (E-91 is the same failure on a single button). Then blur it — add blur(2px) — and ask what the screen is for and which element matters most.

When nothing can render it, use the analogue: if all type were one size and one colour, would the layout still communicate its order? If the hierarchy depends entirely on type styling, it is too weak. The analogue is a fallback, not an equal — a reading of the source is not a look at the page.

Step 6: Decide how it collapses

A spec writes a composition per size. This step is what happens between them: the same content, arranged for less room. Six rules, and the first is the one everything else follows from.

  1. 1.
    Reduce the count, never the size. Four columns become two, then one; each column keeps its own minimum width. Three columns at a third of the width are still three columns, and that is the failure D-111 names — a shrunken desktop rather than a composition. The same applies to a row of controls: it wraps, stacks or moves behind one control, and it does not get smaller.
  2. 2.
    Order survives. What is read first at the widest size is read first at the narrowest. Collapsing rearranges space, not meaning, and the markup order is the reading order at every width (H-119).
  3. 3.
    Distinction survives. If one item was emphasised — a recommended plan, a current step — it is still distinguishable after the collapse. Emphasis carried by position alone disappears the moment everything is in one column, so it needs structure too (E-91).
  4. 4.
    Type comes from the scale, not from breakpoints. The heading tokens are fluid: they track the viewport between a floor and a ceiling with no media query at all. A hand-written ladder of sizes per breakpoint reintroduces the jumps the scale exists to remove, and goes stale the moment the scale changes.
  5. 5.

    Content that is genuinely wider scrolls inside itself, except in editorial on a phone. A code block, a wide table, a long identifier: its own container scrolls with a visible edge (E-62), keeps its type size, and the page never scrolls sideways (D-115). editorial allows no scrolling region on mobile (M-01), so there each one reflows instead:

    • A code block keeps its line breaks and indents and wraps a long line (white-space: pre-wrap, overflow-wrap: anywhere). What is copied is the source as written, not the wrapped lines.
    • A table too wide to fit stacks its rows: each row a block, each cell a line with its column's name in front. It stays a <table> with its header row, so a screen reader still reads it as one. Where it fits, it stays a table: the switch is the width at which its columns stop fitting.
    • A long identifier (a URL, a hash, a file path) breaks where it must (overflow-wrap: anywhere).
  6. 6.
    Each transition happens where the content needs it. The width at which three columns stop fitting is a property of the columns, not of a device. Set it from the content, and expect the numbers to differ per component.

A collapse that satisfies all six looks like the same page with less room. One that fails them looks like a different, worse page that happens to share its content.

Kind
Spec
Section
Components and layout

Read as plain text