How does `grid-template-areas` place items in a CSS grid, and what makes an areas declaration invalid?

## The idea Line-based placement puts the layout knowledge in the children: each item states which lines it sits between. `grid-template-areas` inverts that. The container draws the map, and each child only says which region it belongs to. ```css .page { display: grid; grid-template-columns: 200px 1fr; grid-template-rows: auto 1fr auto; grid-template-areas: "header header" "sidebar main" "footer footer"; } .page > header { grid-area: header; } .page > nav { grid-area: sidebar; } .page > main { grid-area: main; } .page > footer { grid-area: footer; } ``` Each quoted string is one row of the grid. Each whitespace-separated token inside it names the cell in the corresponding column. The extra spaces used to line the tokens up are purely cosmetic — they make the declaration legible as a diagram, which is the whole point of the syntax. ## How an item matches `grid-area: header` sets all four placement values to the identifier `header`, which resolves to the named area's edges. Nothing in the item's rule mentions rows, columns or counts, so a child can be moved to a completely different part of the layout by editing only the container's map. Items with no matching `grid-area` are not affected by the map at all; they are placed automatically like any other unplaced item. ## Empty cells A `.` token marks a null cell — a cell that belongs to no named area. Any unbroken run of dots counts as a single null cell, so `...` and `.` are equivalent, and people often use a run to keep the columns visually aligned: ```css grid-template-areas: "header header" "..... main"; ``` Null cells are still real grid cells: automatically placed items can land in them, so a `.` reserves nothing. It only means "no named area here". ## The two validity rules **Every row must declare the same number of cells.** `"a a" "b"` is invalid because the second row has one token where the first has two. **Each name must form a single filled rectangle.** All the cells carrying a given name must be contiguous and together make a complete rectangle with no notches. These are invalid: ```css /* L-shaped: 'a' is not a rectangle */ grid-template-areas: "a a" "a ." ; /* split: two disconnected regions share a name */ grid-template-areas: "a b" "b a"; ``` A useful consequence: the same name may appear many times, but only in a block. `"header header"` is one area two columns wide, not two areas that happen to share a name. ## Failure is silent and total An invalid `grid-template-areas` value is not partially applied. Per the usual CSS rule, the whole declaration is dropped, so the container ends up with no named areas — and every item whose only placement was `grid-area: <name>` now resolves that name against a line that does not exist, so the items fall back to automatic placement. The classic symptom is a page-shaped layout collapsing into one column after a small edit, and the cause is almost always a missing token or a name that stopped being rectangular. Browser devtools grid overlays name the areas they recognise, which is the fastest way to confirm the declaration was accepted at all. ## Rows and columns still have to exist `grid-template-areas` defines the *shape* of the explicit grid, but not the sizes. Track sizes come from `grid-template-columns` and `grid-template-rows`, and if the areas map declares more rows than the row template does, the remaining rows are still created — they simply take their size from the automatic row sizing rather than from your template. Writing the two side by side, with the same number of tokens per row as you have column tracks, keeps the picture honest. ## Why interviewers like this syntax It makes responsive restructuring cheap. A media query can rewrite the whole layout by replacing one declaration: ```css @media (width < 40rem) { .page { grid-template-columns: 1fr; grid-template-areas: "header" "main" "sidebar" "footer"; } } ``` No child rule changes, and the visual order can differ from the source order — which is exactly where an interviewer may probe: reordering regions this way does not reorder the DOM, so keyboard and screen-reader order still follows the markup, and a map that fights the source order is an accessibility problem, not just a styling choice. ## When not to use it Areas suit named, stable regions — page chrome, card internals, form sections. They suit repetitive grids badly: you cannot name a hundred cells, and a gallery of identical items wants automatic placement with a span where needed. Mixing the two in one container is fine, and common: name the structural regions, let the rest flow.