A CSS Grid with grid-template-columns: 1fr 1fr holds a long unbreakable string in one cell, and that column grows past its half, overflowing the container. Why does 1fr not keep the columns equal, and how do you fix it?

## The bug, precisely ```css .grid { display: grid; grid-template-columns: 1fr 1fr; } ``` Put `supercalifragilisticexpialidocious-and-then-some` in the first cell and the first column stops being half the width. Nothing in the CSS mentions content sizing, so the behaviour looks like a browser bug. It is not. ## fr is a maximum, not a size The track sizing algorithm resolves flexible tracks *last*. Before it distributes any free space, it sizes every track's **base size** from its minimum, and only then grows tracks toward their maximum with whatever space is left. A bare `1fr` expands to: ```css grid-template-columns: minmax(auto, 1fr) minmax(auto, 1fr); ``` The minimum is `auto`, not `0`. So step one already gives the offending column a base size equal to what its content demands, and there is no mechanism later that takes it away — flexible sizing can grow a track above its base size but never below it. ## What `auto` as a minimum actually means For a grid item whose `overflow` is `visible`, an `auto` minimum resolves to the **automatic minimum size**, which is essentially the item's min-content contribution. Concretely: - A paragraph's min-content width is its longest unbreakable run — a long word, a URL, a hash, a filename with no hyphens. - A replaced element such as an `img` contributes its own intrinsic minimum unless constrained. - A nested element with its own content-driven minimum passes that minimum up the chain, so the culprit is often two or three levels deep. That last point is why the same bug in a real app is so hard to see: the wide thing is a `pre` block or an overflowing table inside a card inside the grid item. ## The three fixes ```css /* 1. Explicit zero floor on the track */ .grid { grid-template-columns: minmax(0, 1fr) minmax(0, 1fr); } /* 2. Zero floor from the item's side */ .grid > * { min-width: 0; } /* 3. A non-visible overflow makes the automatic minimum zero */ .cell { overflow: hidden; } ``` They are not interchangeable in intent: - `minmax(0, 1fr)` is the most declarative — the track list itself says "these columns are exactly equal, whatever is inside them". It is the right default for layout grids you control. - `min-width: 0` is the right tool when only some items misbehave, or when the grid's track list is generated elsewhere. Its logical equivalent is `min-inline-size: 0` if you are writing writing-mode-agnostic CSS. - `overflow: hidden` (or `auto`, or `clip`) fixes the sizing as a side effect of establishing a scroll container. Reach for it when you *want* the clipping or the scrollbar, not merely as a sizing hack, because it also silently clips shadows, focus rings and popovers that used to escape the box. Removing the floor makes the track equal, but the content still has to go somewhere. Usually you pair the fix with a content rule: ```css .cell { min-width: 0; overflow-wrap: anywhere; /* let the long token break */ } .truncated { min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; /* ellipsis needs all three, plus the zero floor */ } ``` The ellipsis case is worth memorising: `text-overflow: ellipsis` inside a grid or flex layout is famous for "not working", and the missing ingredient is almost always the automatic minimum size keeping the box wide enough that there is nothing to truncate. ## The same rule elsewhere The automatic minimum size is not a grid-only concept — the same content floor is why supposedly shrinkable boxes refuse to shrink in other layout modes too, and the same `min-width: 0` remedy applies. Recognising the symptom ("one box is wider than its share and the container overflows") is worth more than memorising which layout mode you are in. ## How to diagnose it in ten seconds In devtools, look at the computed track sizes rather than the elements: if one `1fr` track reports a width larger than its siblings, the track's base size is content-driven and you are in this situation. Temporarily setting `minmax(0, 1fr)` and watching the overflow disappear confirms it. If the overflow persists, the culprit is a fixed width or a padding sum inside the item, not the track floor. ## Why the default is this way It is deliberate: silently shrinking a track below its content's minimum would clip or overlap content by default, which is worse than an overflow you can see. CSS chooses visible breakage over invisible data loss, and asks you to opt in to the zero floor when you know clipping or wrapping is acceptable.