Formatting contexts.

Two layout bugs landed in Slatework's tracker in the same week. In the activity panel, a teammate's round avatar dangles below her one-line comment and nudges the first line of the next entry to the right. On the board, someone attached a file whose name is a single unbroken link, and the Review column swelled to more than four times the width of its neighbours, which shrank to slivers. Neither fix is a magic property you memorise. Both fall out of one question: which box's rules is this element being laid out by?

The answer is almost never the element itself. display has two halves. The outer half says how the box takes part in whatever its parent is doing: as a block-level box or an inline-level one. The inner half says what the box does for its own children: keep flowing them as blocks and lines (flow), flow them in a fresh, sealed block context (flow-root), or run flex, grid or table layout on them. So a span inside a paragraph sits on a line like a word, while the same span inside a flex container becomes a flex item: its inline display is quietly turned into block, and the flex algorithm sizes it.

Most block boxes simply continue the context they are in: a div inside a div joins the same block formatting context, so a float in one can reach into the other and margins can merge across their edges. Some boxes open a new context instead. A new context is a wall: everything inside is laid out by rules that start fresh at that box, and the outside sees one rectangle. Flex and grid containers are always walls. For ordinary block content you choose to build one, most cleanly with display: flow-root, and that is the whole fix for the dangling avatar.

Many properties open a new BFC as a by-product of their real job. That is why people reach for overflow: hidden to stop a float leaking and then wonder, a week later, why a dropdown is cut off. Read the right-hand column before choosing a trigger: only flow-root does nothing else.

Floats are the reason block formatting contexts exist in the form they do. A float belongs to the BFC it is laid out in, not to its parent element. An ordinary block that contains only a float has nothing in flow, so its automatic height ignores the float and the float hangs out of the bottom. Blocks that come later in the same BFC run straight underneath the float; only their line boxes get shorter so the words avoid it.

Opening a new BFC changes three things. First, it contains its floats: the spec gives a BFC root with automatic height enough room to reach the bottom of the floats inside it. Second, it avoids floats outside it: a BFC's own border box is placed beside a float in the surrounding context instead of running under it, so its text forms a clean column instead of wrapping around the corner. Third, margins stop at its edge: a child's top margin can no longer collapse through the parent and push the parent down (the collapsing rules themselves are in the box model topic).

A flex or grid container lays out its children with its own algorithm, so the children's outer display stops mattering. The browser blockifies them: an inline outer display is computed as block (inline-flex becomes flex, inline-grid becomes grid), and a run of loose text directly inside the container is wrapped in an anonymous item. Properties that only made sense in block or inline layout go quiet: float and clear do not take an item out of flow, and vertical-align does nothing to it.

Each item then lays out its own children in a fresh context. A plain item becomes a new block formatting context, which is why a Slatework card in a flex column contains its floats without any help. An item that is itself display flex or grid starts that kind of context instead. The container is just as sealed toward the outside: floats around a flex or grid container do not reach into it, and its margins never collapse with its items' margins.

Flex and grid size things from their content, so they need to ask each item two questions. How narrow can you get? That is the min-content size: the width when every soft wrap opportunity is taken, usually the longest word or unbreakable run. How wide would you like to be? That is the max-content size: the width with no wrapping at all. fit-content sits between them: as wide as the space allows, never narrower than min-content, never wider than max-content.

Here is the trap. In block layout min-width defaults to 0. On a flex item, along the main axis, min-width auto means something else: an automatic minimum equal to the item's content-based minimum, which in practice is its min-content size unless a smaller width is set. flex-shrink lets an item shrink, but never below that floor. A task title with spaces has a small min-content and shrinks happily. A file name joined by underscores, with no space or hyphen anywhere, has no soft wrap opportunity, so its min-content is the whole name; its item refuses to shrink, and the row overflows its card.

Three things lower the floor. min-width: 0 removes it, so the item shrinks to its share and the text inside can wrap or truncate. overflow hidden, auto or scroll makes the item a scroll container, and scroll containers get an automatic minimum of 0, but the item now clips (overflow: clip is not a scroll container, so it keeps the floor). overflow-wrap: anywhere lowers the min-content size itself by counting break opportunities inside the name; overflow-wrap: break-word wraps the same way at paint time but is ignored when min-content is computed, so on its own it does not fix a flex item. Grid has the same floor in another place: 1fr is shorthand for minmax(auto, 1fr), so a track grows to its widest item's minimum unless you write minmax(0, 1fr).

Every trigger above opens a context as a side effect of something else. The contain property states the intent directly. contain: layout promises that nothing inside the box affects layout outside it and nothing outside affects layout inside, and the browser enforces the promise by making the box a new block formatting context, a containing block for absolute and fixed descendants, and a stacking context. contain: paint adds clipping to the box's bounds. contain: content is shorthand for layout, paint and style; strict adds size containment, which makes the box ignore its children when sizing itself, so it needs an explicit size.

The reason to reach for it is performance, not float containment: when a contained subtree changes, the browser knows the change cannot ripple outward, so it can relayout less. That is rendering-performance territory (containment and content-visibility on large lists are taught there). The thing to remember here is the bundle: contain: layout on a Slatework card would also capture the card's fixed-position children and start a new stacking context, which the next two topics show can move a menu or a toast in ways nobody intended.