Mobile

One layout, narrowed

Every page is built from components that stack by default and split when there is room. The narrow state is not a fallback bolted on at the end: it is the state the CSS starts in, and the wide layout is what a query adds. A component that is never asked about its width is already correct on a phone.

That is why almost nothing here asks the viewport. A component asks its container, so the same card is right in a 1280 px content column, in a half-width split and in a 375 px phone without knowing which it is in. Only furniture genuinely pinned to the screen — the nav bar, the hero, the footer, the consent banner — is allowed to ask the viewport, and each of those exceptions is written down in the breakpoint register in tokens.css.

What changes continuously

Before any threshold fires, three things are already moving with the viewport. They are clamp()s, so each has a floor, a ramp and a ceiling, and the widths where the arms swap are as real as a breakpoint — they are just not queries, which is why the register deliberately leaves them out.

All four type floors land within 8 px of each other, just under the narrowest phone in use. 359, 360, 361, 367 — the scale stops shrinking at about 360 and holds. That is worth knowing because it means a 320 px device and a 360 px device get identical type; only the gutter and the measure differ. Measured at 320 and at 360: display-1 is 40.00 and 40.04 px.

Body copy is 14 px at every width and does not participate. It is not a display size, it is the reading size, and a reading size that changes with the window is a reading size nobody has tuned. What changes on a phone is the measure, which the gutter and the single column take care of.

The order things happen in

Widest to narrowest, every layout change a page makes on the way to a phone. Each row was found by binary-searching the viewport width on the pattern page named — set the window one pixel either side of the number and the state flips.

Drawn to scale across 320 → 1280. The last flip is at 612; the 375 row is a phone, marked for scale.

Nothing happens between 612 and 320. Every threshold in the system is above the widest phone, so a phone is not a special width the layout switches into — it is the far end of a ramp the layout has already been on since a laptop. The last 300 px of narrowing change only the gutter and the measure.

The phone column

Below 612 every component is in its narrow state, and the page is one column of full-width blocks separated by 64 px of section gap. Real pages, live, at 375:

Scroll them. They are the same files the patterns section serves, in a 375 px frame — not screenshots, and not a mobile build. The consent banner is showing because each frame is a first visit, which is worth seeing here: it is the single-column, full-width-button state the table below describes, and on a phone it covers about a third of the screen until it is answered.

What each component does

Touch, not pointer

A phone has no hover and a fingertip is about 9 mm across. Two consequences, both checkable.

Nothing is hover-only

Every hover in the system is an enhancement of something already visible: the button's specular travel, the nav link brightening, the card's rule inking, the arrow's 4 px nudge. Remove hover entirely and no state, no label and no destination becomes unreachable. The one place this was a real risk — the current-page marker in the navigation — is drawn with ink and a plate rather than a hover, which is also why it survives on touch. → Navigation

Target sizes, measured

Every interactive element on all 18 pattern pages, at a 375 × 812 touch viewport. This table was four rows for a long time — measured honestly, with the gap stated in prose rather than closed with an estimate — and the four rows it held were counted before the landing page was rebuilt around the acts, so they described a page that no longer exists. All fifteen have now been through the same element-by-element count in one run. Documentation chrome is excluded: .ds-back is position: fixed, drifts over the page as it scrolls, and the site build strips it from the shipped root pages anyway, so counting it would measure an element no reader of the shipping page can touch. The skip link is excluded on the same argument from the other side: it rests at translateY(-200%) and is on screen only once a keyboard has already found it, so no fingertip meets it as a target.

WCAG 2.2 AA (2.5.8, Target Size Minimum) passes on all 18. The requirement is 24 × 24 CSS px or enough space around a smaller target that a 24 px circle centred on it touches no other target's circle. Every element under 24 px is an inline text link — footer meta, legal lines, the address — or the footer's wordmark, 139 × 20 on every page since the footers were unified, and every one of them clears the circle test, or is exempted as a target inside a sentence, checked pairwise against every other control on the page, at 320 and 768 as well as 375, because a wrap point moves targets past each other and a single width cannot see that. A wrapped inline link is measured as its line boxes rather than its bounding box, which unions the lines and manufactures overlaps that exist in no reader's hand. 54 page-widths, zero failures. The closest pair anywhere is on impressum at 375 and 390, and it is the one pair in the whole sweep whose circle-test verdict depends on which rendering engine measures it — the note below is that pair's history, and it is worth reading before trusting the margin.

Every plate-shaped control clears 48 px, because .cf-btn carries min-height: 3rem and the accordion row carries 4 rem. Two things sit between 24 and 44 — legible, tappable, and short of the 44 px convention (WCAG 2.5.5 AAA, and Apple's HIG):

Text, zoom and the URL bar

Every page carries width=device-width, initial-scale=1 and nothing else. No maximum-scale, no user-scalable=no: pinch zoom works everywhere, which is not a nicety — it is how a large share of people read on a phone at all.

-webkit-text-size-adjust: 100% is set on html. That is not a zoom lock either; it switches off iOS Safari's own text inflation in landscape, which would otherwise resize some blocks and not others and quietly break every measured line length on this site. Reader-initiated zoom is untouched.

Viewport units, and where they bite

All three start from vh — deliberately, and it is worth knowing which behaviour that buys. vh is the large viewport: it resolves as though the URL bar were collapsed and does not change while the bar slides away, so nothing reflows mid-scroll. The cost is that the hero is a little taller than the visible screen on first paint, which is the direction of error this layout wants — the hero is meant to run past the fold. Everything clipped rather than scrolled carries dvh on top for the opposite reason: a clipped box has no reflow to avoid, so an oversized cap has nothing paying for it, and Safari's own toolbar leaves a crop-shaped gap — or, anchored to an edge instead of cropped, lets the box grow past where the cap meant to stop it — if nothing tracks the toolbar down. That is the two pinned stages (the values track here, the Expertise and landing-page builds) and, since the note below, the consent backstop too.

What does not happen on mobile

Checking it yourself

Everything on this page is reproducible in a browser with no tooling. Open a pattern page, narrow the window, and watch for four things in this order: does the document scroll sideways; does any block overflow its gutter; does every control stay tappable; does anything that carries meaning disappear.

// paste in the console at any width — the only test that matters first
document.documentElement.scrollWidth - document.documentElement.clientWidth
// 0 means the page fits. Anything else, find the culprit:
[...document.querySelectorAll('body *')]
  .filter(el => el.getBoundingClientRect().right > innerWidth + 1)
  .map(el => el.className || el.tagName)

The threshold numbers in the table above were found the same way, by binary search: set the viewport, read a computed style, halve the interval. That is why they are given as narrow at n, wide at n+1 rather than as the round number in the query — a container threshold and the viewport that produces it are two different numbers, and only one of them is what you can check with a window.