A CSS Grid has grid-template-columns: 1fr 1fr, and one auto-placed item declares grid-column: span 3. What does the browser do?

## The implicit grid is sized before placement runs It is tempting to think of auto-placement as a single walk that grows the grid as it goes. It is not: the algorithm first fixes how wide the grid is (in row flow), then walks. One of the inputs to that width decision is the **largest column span among items that have no definite column position**. If that span is larger than the number of columns the grid otherwise has, columns are appended to the end of the implicit grid until the span fits. ```css .grid { display: grid; grid-template-columns: 1fr 1fr; } .wide { grid-column: span 3; } ``` Two explicit columns, a request for three, so the implicit grid ends up three columns wide. Every item in the container now lays out against a three-column grid, not just the wide one. ## Explicit vs implicit is not cosmetic here The two columns you wrote are **explicit** tracks with the size you gave them (`1fr` each). The third is an **implicit** track, and implicit column tracks take their size from `grid-auto-columns`, whose initial value is `auto`. So the layout is not three equal columns: the third sizes itself to its content, and the two `1fr` tracks divide whatever free space is left after it. Developers who expect `repeat(3, 1fr)` behaviour are surprised by the ragged result, and the fix is either to widen the template or to set `grid-auto-columns` deliberately. ```css .grid { display: grid; grid-template-columns: 1fr 1fr; grid-auto-columns: 1fr; /* now the generated column matches */ } ``` ## Why this is asymmetric with rows In the default `grid-auto-flow: row`, the column count is a **fixed frame** and the row count is **open-ended**: items that run out of room generate new rows indefinitely, but nothing generates a new column merely by overflowing — the cursor wraps instead. A span wider than the frame is the exception, because there is no way to satisfy it by wrapping. Switch to `grid-auto-flow: column` and the roles swap: the row count becomes the fixed frame, and an oversized `grid-row: span n` widens it the same way. ## What this is not - **It is not clamping.** Browsers do not quietly reduce `span 3` to `span 2` to make it fit. - **It is not overflow.** The item does not spill past the container's content box; the grid genuinely has an extra track. - **It does not shrink the item's content.** Track sizing runs after placement, on the grid that placement decided on. One related detail worth keeping straight: this expansion happens for spans, which are *relative*. Placement that names an explicit line is a different mechanism with different behaviour, so do not generalise from one to the other. ## Reading the layout back When a grid mysteriously has one more column than you wrote, the diagnostic path is short: look for an item whose `grid-column` contains a `span` larger than your track count. This often happens accidentally — a `span 3` written for a three-column desktop layout, still applied inside a media query where the template dropped to two columns. The visible symptom is a narrow ragged extra column that no rule seems to define. Making spans responsive alongside the template (`grid-column: auto` or a smaller span at narrow widths) is the usual fix. ## What to say in an interview State the outcome first — the grid gains a column, the span is honoured — then the nuance that the new column is implicit and therefore sized by `grid-auto-columns` rather than by the template. Adding the row/column asymmetry (overflow makes rows, oversized spans make columns) shows you understand the frame-versus-flow shape of the algorithm rather than a memorised fact.