In a CSS Grid container, where do grid items end up if you never set grid-column or grid-row on them?

## Auto-placement is the default, not a fallback When you write `display: grid` and define tracks, you are describing a coordinate system: a set of column lines and row lines that carve the container into cells. You *may* address a cell explicitly with `grid-column` and `grid-row`, but you almost never have to. Any grid item that does not carry a definite position is placed for you by the **auto-placement algorithm**, and in a typical card gallery or form layout that is every single item. ```css .gallery { display: grid; grid-template-columns: repeat(3, 1fr); gap: 1rem; } ``` With that stylesheet, ten children get ten cells: three in the first row, three in the second, three in the third, one in the fourth. No child needs a rule of its own. ## What counts as a grid item Only the **direct children** of the grid container become grid items. Grandchildren are laid out inside their parent item by whatever rules apply there. Text directly inside the container is wrapped in an anonymous grid item. This matters because auto-placement operates on that flat list of children, in the order they appear in the document. ## The cursor, in plain terms The algorithm keeps a **placement cursor** — a row/column pointer that starts at the first row and first column of the grid. For each auto-placed item, in document order, it looks for the next empty area big enough for the item, places it there, and leaves the cursor just past it. Because `grid-auto-flow` defaults to `row`, the cursor advances column by column across a row before moving down to the next row. Set `grid-auto-flow: column` and the same walk happens down each column instead. Two consequences fall straight out of this: - **Document order is visual order.** Reordering the markup reorders the layout. This is why grid layouts stay accessible by default: the reading order the screen reader and the Tab key follow is the same order you see. - **Auto-placed items never overlap.** The algorithm only ever chooses empty areas. Overlap is possible in grid, but you have to ask for it with explicit placement. ## Explicit items go first The algorithm is a sequence of passes. Items with a definite position on both axes are placed first; items locked to a specific row (or column, in column flow) come next; everything else is auto-placed last, flowing around the cells that are already taken. ```css .hero { grid-column: 1 / 4; } /* placed first, occupies all of row 1 */ .card { /* auto-placed; starts on row 2 */ } ``` So you can pin one banner into a known area and let the rest of the content arrange itself around it, without giving every card coordinates. ## Spans still participate An auto-placed item can declare a size without declaring a position: `grid-column: span 2` says "two columns wide, you pick which two". The algorithm then looks for the next empty run of two columns. This is where the layout can surprise you: if the cursor sits in the last column and the next item needs two columns, that last cell stays empty and the item starts on the following row. ## Running out of rows If you defined three rows and have twelve items in a three-column grid, the fourth row does not exist in your template — the grid creates it. Those generated tracks size themselves according to `grid-auto-rows` (its initial value is `auto`, i.e. content-sized). Practically, this is why a grid whose item count changes at runtime — a search-results list, a paginated gallery — needs no extra rules: you describe the columns, and the rows appear as needed. ## What a junior should be able to say Name the default flow direction (`row`), say that items fill in document order one per cell, and note that explicitly placed items are handled first. Then show you know the escape hatches exist — `grid-auto-flow: column` to flow down instead of across, and per-item `grid-column`/`grid-row` when a specific item really must live in a specific cell.