Card grid

The track, with bricks in it

Three cards in the real .grid, both themes, the markup the 23 screens ship. The cell is the width the widest column at 1280 gives it, so the track resolves the same number of columns here as it does there.

Two things in this specimen are written by hand and are written by a machine in the product, and both are the reason this page had no specimen at all until 2026-08-09. The photograph is an inline style, one of the three the rules allow, and it is a DATUM: without it the thumbnail is a grey box, which is what all ten cards on the shelf were. The odds bar is in no screen's markup: a page script reads .prob-line .prob, builds the bar, hides the line and inserts it before .yesno. A stand does not run the product's scripts, so it writes what the browser renders, exactly as the card's own page does.

One brick, many of it, and that is still a composition

A grid of one component sounds like the component's business and is not: what the pattern decides is the TRACK, and the card decides nothing about where it stands. The shelf and the reason stay on the patterns page.

The count was taken from the markup and not by searching for a word. The name also matches the chart's grid line on nine more screens and one hero class on another, and neither of those is this. 23 elements on 23 screens.

The one !important, and what it was arguing with

Four rules used to sit beside the track: three breakpoints stepping the grid two, three and four columns, and a category variant. All four were already dead. The three breakpoints lost to the fluid rule on source order alone, and the category variant was outranked only by the shout that rule was carrying.

So the shipped grid has always been the one rule, and the !important was holding up a cascade nobody had cleaned. Deleting the four is what made it removable without moving a card.

A fluid track needs no breakpoints, which is also why this pattern has no media query of its own. Three dead breakpoints are what a grid looks like when it was written before the fluid rule and never re-read afterwards.

One column to four, and 1280 gives two

The file says one column to four and 1280 gives two, and both are true. The track asks for cards of at least 300 with a 16 gap, so three need 932 of grid and the widest column at 1280 is 911. Four needs about 1,264 of grid, which is a window somewhere past 1,400. It is worth writing down because "one to four" reads as a range a person can see, and two thirds of it is off the end of the widest reading this kit takes.

The minimum is written min(100%,300px) rather than 300, which is what stops the track overflowing a column narrower than a card: at 293 the card takes the column instead of pushing past it.

The rule

A fluid track replaces a set of breakpoints. One rule, no queries, and the column count falls out of the width it is given.

A minimum that can exceed its container is an overflow. min(100%,300px) is the whole guard.

The card decides nothing about where it stands. The track is the pattern's and the brick is the component's.

The anti-rule

Never leave a shout in place. It was outranking one dead rule and hiding three more, and removing all four moved no card at all.

Never count a pattern by searching for its class name. The same word matches a chart line on nine screens and a hero on one.

Never add a breakpoint to a fluid track. Three of them lost on source order and stayed in the file for months.

Where the rest of it is

The shelf: the patterns page. The stylesheet: components/patterns/card-grid.css. The brick: card. The column it stands in: browse shell. Its loading face: skeleton.