The list column
A page that is a column of grouped rows, opened by a line that says what the column is. Settings, Alerts, Connections and Data and privacy are all this shape, and on a desktop none of them uses the width of the pane: the column stops at a reading measure and the rest of the page stays quiet.
Anatomy
An intro, then whatever the screen groups, in one narrow column. The composition is the ORDER and the measure rather than the list of members: what follows the intro differs on all four screens and none of that is the pattern's business.
You
Your details, your plan, and the two screens that hold everything about your data.
Your plan
Behaviour at width
From --bp-tablet, 47.5rem: the column takes --container-column, 38.75rem. One query in the pattern's own file, and it reaches every screen the pattern stands on, including the ones that do not exist yet. That is the whole return on lifting a composition into a pattern before the adaptation rather than after it.
The measure is bound through > .screen > at 0-3-0 so it survives the shell's blanket max-width: none past the desktop point. See Width.
A plain copy of everything we hold is free and always will be.
.rows-colthe pattern keeps the class the product already writes. It was the exact marker of this composition on all nine pages, so renaming it would have been markup churn on nine files to arrive at the same set. The two patterns that had no such marker were given one.textblockthe intro, and it is the first block or this is not the pattern. It answers "what is this column" before a person starts reading rows.groupand.divlist,.card,.switch: whatever the screen groups. Settings groups fields and then nav rows, Alerts groups alert items, Connections groups source cards, Data and privacy groups switches. The category group and the divided list are the two that appear on every one of the fourmin-width: 0the floor. The default minimum of a grid or flex child is "as wide as my content refuses to get narrower than", and one long unbroken string widens the track and pushes the layout sideways. Cut fromapp-shell.csswith the measure belowmax-width: 620pxthe reading measure, from the 760 container up. The same 620 the onboarding chain uses for a column of prose, and the reason a settings page on a 1280 screen is not a 980px line of text
Variants
None, and the absence is load bearing. The four screens differ by what they group and by nothing else. A wider variant would be a second reading measure with no reason, and a variant with the intro somewhere other than first would be a different composition. The one thing that changes across widths is the measure itself, and it changes once, in the container query.
| Width Set by the container, which is |
Measured | What happens |
|---|---|---|
| Under 760 | 328px at a 360 viewport | The column is the screen, minus the screen's own 16px of side padding. No measure applies and none is needed |
| 760 and past it | 620px at a 1280 viewport | The shell has become a two track grid with a 220px rail, and the pane it leaves is 1060 wide. The column takes 620 of it and stops. Rows that are 620 wide are read; rows that are 1060 wide are scanned and then re-read |
| A second column beside it | - | That is the two-track detail, and it is a candidate rather than a pattern: two screens today, waiting for a third. A list column that grows a second column is not this pattern widened, it is that one |
When to use it
For a screen whose whole content is one list of things a person scans and taps into. In ia/docs/flows.md these are the screens off the tab bar rather than inside a flow: You, Alerts, and the two screens behind them. They are the calm rooms of the product, visited deliberately, and the intro at the top is what makes each one answerable in a sentence.
Not for Home. Home is also a column of grouped rows and it is deliberately not this pattern: it carries a dashboard head with the total, it reorders its blocks past 900, and its groups run in two and three columns from the groups column set. That is one screen's own arrangement and it stays in the screen. The list column is for the screens where the list is the whole point and the width is the only decision.
The rule, and the anti-rule
Alerts
What changed, and what is about to. Nothing here needs an answer today.
This week
Two lines that say what the column is and how much attention it wants, then the rows. On a screen about alerts, the second sentence is the product's whole promise about alerts.
This week
What changed, and what is about to. Nothing here needs an answer today.
The same words, arriving after they were needed. A person who lands on a list of changes to their money reads the first row with no idea whether it is urgent. The intro is not a heading habit, it is the sentence that sets how hard the rows are read, and this product is built for people who arrive nervous.
Connections
The banks you have connected, and what each one is showing.
At 1280 this is 620px wide inside a 1060px pane, and the empty space to the right is the design. A settings row is a line of text with a control at the end of it, and both are found faster when the line is short.
A contextual override is an undeclared variant, and this one would put one screen's rows at a different measure from the other three with nothing recording the decision. If a screen genuinely needs a different width, that is a variant of the pattern, declared in patterns/list-column.css with a modifier class and a reason. The rule is in Architecture and it holds for patterns exactly as it holds for components.
Limits
U5, composition. One introductory text block per column, and it is the first block. U3, composition. The screen around it carries exactly one app bar. Full table with sources: Usage rules.
Where it stands
Nine pages across four screens in the grey product, and the count is of the COMPOSITION rather than of the class: ten grey pages and six coloured ones write .rows-col, and the tenth and sixth is the same page, alerts-error, which wears the container and puts an interruption inside it instead of a list. It is counted there, so that no page is counted twice across the three patterns. Five of the nine are in colour today: Settings with and without an account, and three states of Alerts, which arrived at stage 09 step 5. It is still the pattern with the thinnest coloured proof of the three, and it is said here rather than left to be discovered.
| Screen | Pages | What it groups | In colour |
|---|---|---|---|
| Settings | settings, settings-no-account | form fields, then nav rows into the two data screens | yes |
| Alerts | alerts, alerts-empty, alerts-loading | alert items, this week and older | yes |
| Connections | connections, connections-empty, connections-reconnect | source cards, one per connected bank | grey, stage 12 |
| Data and privacy | data-privacy | switch rows, then the export and delete doors | grey, stage 12 |
The error state of Alerts wears the class and not the composition, and the distinction is the reason this table has a row it does not count. alerts-error writes .rows-col, so it takes this file's two declarations exactly like the other nine; what it puts inside the container is not a column of grouped rows but an interruption. Two patterns, one container, both true at once, and the page is counted on the interruption so that no page is counted twice across the three. Nine and five are the composition; ten and six are the selector.
The technical half
| Declares | Value | Where it came from |
|---|---|---|
| the floor | min-width: 0 | cut from app-shell.css, where it was the .rows-col half of a declaration shared with .form-col. The form column keeps its half there, because one screen is not a pattern |
| the reading measure | max-width: 620px from the 760 container | cut from app-shell.css. A width is on neither scale of this system, so 620 is a literal, documented rather than tokenised, exactly as the shell wrote it |
| colour, type, radius, elevation | none | a pattern arranges components and reads tokens |
This is the only one of the three patterns that is a move rather than a first writing. Both rules existed, both were in the shell because there was no shelf above the shell to put them on, and both left it: app-shell.css has neither now, so there is one home and no cascade race. Measured before and after at 360 and 1280 on both coloured pages: 328 wide at 360, 620 at 1280, identical on both sides of the move.
<main class="screen">
<div class="rows-col">
<div class="textblock">
<h1>You</h1>
<p>Your details, your plan, and the two screens that hold everything about your data.</p>
</div>
<section class="group" aria-label="Your details">...</section>
</div>
</main>