In CSS Grid, when is grid-auto-flow: dense the right choice, and what cost do you accept by using it?

## What dense actually changes `grid-auto-flow` carries two things: a direction (`row` or `column`) and a packing mode. The packing mode is *sparse* unless you write the `dense` keyword, as in `grid-auto-flow: row dense` (or just `dense`, which implies row flow). In sparse packing, the placement cursor only moves forward, so a cell that was skipped is stranded. In dense packing, **the cursor is reset to the start of the grid for every auto-placed item**. Each item is offered the earliest empty area big enough for it, which means a narrow item that comes later in the DOM can drop back into a hole a wide item left behind. ```css .gallery { display: grid; grid-template-columns: repeat(4, 1fr); grid-auto-flow: row dense; } .gallery .feature { grid-column: span 2; grid-row: span 2; } ``` The result is a compact mosaic with no holes — the effect people are usually chasing when they say "masonry". Note that it is not the same thing: dense packing still uses the row and column tracks the grid defines, so items stay aligned to shared row boundaries. It removes holes; it does not stagger items into offset brick courses. ## The cost, stated precisely Dense packing changes **only the visual arrangement**. It does not touch the DOM, and everything derived from the DOM keeps the original sequence: - The **accessibility tree** and therefore screen-reader reading order. - **Sequential focus navigation** — the Tab key visits focusable descendants in DOM order. - **Find-in-page**, text selection, and copy order. So a card that appears second visually may be the ninth thing announced and the ninth thing focused. For a keyboard user, focus appears to jump around the page unpredictably; for a screen-reader user, the description of the layout no longer matches what a sighted colleague sees on the same screen. This is the same class of defect as flexbox's `order` property, and it maps onto well-known accessibility requirements: content must be presented in a meaningful sequence, and focus order must preserve meaning and operability. The important nuance is that this is a defect **only when order carries meaning**. A wall of unrelated product photos has no meaningful sequence to destroy. A ranked leaderboard, a numbered checkout flow, a chronological feed, or a list of form fields does. ## A usable decision rule Use `dense` when *all* of these hold: 1. The items are **order-insensitive** — shuffle them and nothing is lost. 2. Each item is **self-describing** — a user who lands on it out of sequence still understands it, without needing "the one above" for context. 3. The items are **not interactive**, or their interactivity is simple and self-contained, so an out-of-order focus jump does not strand the user mid-task. 4. The holes are actually visible and actually bother the design — dense costs nothing to add, but it also buys nothing if there are no holes to fill. If any of those fail, prefer the alternatives: change the track count so spans divide evenly, drop or shrink the span at problem breakpoints, or reorder the source itself so the visual order you want *is* the DOM order. ## Second-order effects to mention **Instability.** Because every item is offered the earliest fitting hole, dense layouts are sensitive to their input. Add one item, change one span, or let one card's content grow, and items can jump to different positions than before. In an incrementally loading list this reads as items shuffling on screen while the user is looking at them, which is worse than a hole. Sparse packing is stable in the sense that earlier placements never change when later items arrive. **Cost of the algorithm.** Dense placement does more searching, since the cursor restarts for each item. For realistic item counts this is not something you should optimise for — but on a grid with thousands of auto-placed items it stops being free. **It does not reorder anything you placed.** Explicitly positioned items are placed before auto-placement runs; dense only affects the items the algorithm is choosing positions for. ## How to answer this in an interview Lead with the mechanism in one sentence (cursor restarts, so later items backfill earlier holes), then immediately name the divergence between visual order and DOM order and what depends on DOM order. Finishing with the decision rule — order-insensitive, self-describing, ideally non-interactive — is what separates "I know the keyword" from "I have shipped this and been bitten by it".