The box model and normal flow.

Slatework's design file says a task card is 320 pixels wide with 16 pixels of padding and a hairline border. A developer types exactly that into the stylesheet, opens the board, and the card is 354 pixels wide and sticks out of its column. Nothing is broken. The browser did what the declaration asked, because by default width means the width of the content only, and padding and border are added outside it.

That is the whole topic in one bug. Before the browser paints anything it builds a tree of boxes from the elements and their computed styles. Each box has a content area for text and children, then padding, then a border, then a margin that keeps neighbours away. Its final size comes from three inputs: what it contains, what its own properties say, and the width its parent makes available.

Then the boxes are placed. Without flex, grid, floats or positioning, the browser uses normal flow: block-level boxes go one under the other, each as wide as its parent allows; inline content such as text and links runs along a line and wraps onto the next one when it runs out of room. Two quirks of that flow, percentages measured against the parent and vertical margins that merge instead of adding up, explain most of the spacing that does not match the mockup.

It is tempting to read display: flex as a description of the element itself. It is really two answers packed into one word. The outer display type says how this box behaves among its siblings: a block-level box takes a line of its own across the parent; an inline-level box sits in a line of text next to its neighbours. The inner display type says how this box arranges its own children: flow (ordinary block and inline layout), flow-root (the same, but sealed off from the outside, which the next topic explains), flex, grid or table.

CSS Display Level 3 lets you write both halves, so display: inline flex is a box that sits in a line of text and lays out its children as a flex row. The familiar single keywords are short forms of the pairs: block means block flow, inline-block means inline flow-root, flex means block flex. Every current engine accepts the two-word form (Chrome since 115, Firefox since 70, Safari since 15), but for everyday layout it adds nothing the single keywords cannot say, so most codebases keep them.

Two values produce no box of their own. display: none removes the element and its whole subtree from layout. display: contents removes only the element's own box and promotes its children, as if the wrapper were not there; it is handy for a wrapper a framework forces on you, but check how the element is exposed to assistive technology, which has had browser bugs. The render pipeline topic covers how this box tree is built from the DOM and styles.

Normal flow moves in two directions, and CSS names them after the writing rather than the screen. The inline direction is the way a line of text runs. The block direction is the way lines, paragraphs and block boxes pile up. In English both are the familiar left-to-right and top-to-bottom; in Arabic the inline direction runs right to left while blocks still stack downwards; in vertical Japanese the lines run top to bottom and stack from right to left.

This matters here for two reasons. Block boxes fill the inline size of their parent and stack in the block direction, whatever the language. And margin collapsing, below, happens only along the block axis, so in a vertical writing mode it is the left and right margins that merge. The flow-relative property names (margin-block, padding-inline, inline-size) simply name the sides of the box this way; when to use them across a product is the right-to-left topic's lesson.

A block box in normal flow is measured against its containing block, which for a box in flow is the content box of its nearest block container ancestor. (Positioned boxes pick a different one; that is the positioning topic.) Across the inline axis the parts have to add up exactly: left margin, left border, left padding, width, right padding, right border and right margin together equal the containing block's width. Leave width as auto and it soaks up whatever is left, which is why a plain div fills its parent. Give it a width and set both inline margins to auto, and the two margins share the leftover equally: the box is centred.

Height works the other way round. An auto height is the height of whatever the box contains, so content decides it after the width is known. That is also why a percentage height often does nothing: if the parent's own height depends on its content, there is nothing fixed to take a percentage of, and the browser treats it as auto. Percentage widths always have something to measure against. A less obvious rule: percentage padding and margin are measured against the containing block's width on all four sides, top and bottom included, which is the old trick behind boxes that keep their shape (aspect-ratio does it directly today).

Inside a block whose children are inline, the browser lays the content out in an inline formatting context. It fills a line box, a strip as wide as the block's content box, with words, links and chips one after another along the inline direction. When the next piece does not fit, it breaks at an allowed spot, usually a space, and starts a new line box under the first one. An inline element that does not fit is cut into pieces, one per line, each with its own share of the background. The block's height is then the line boxes stacked.

Inline boxes do not get a say in that height. width and height are ignored on a plain inline element such as a span. Horizontal padding, border and margin push neighbours along the line. Vertically, margins do nothing and padding and border only paint: the chip's background grows up and down and may overlap the line above, while the lines stay where line-height put them. When a piece of the line needs real height, make it inline-block (or inline-flex): it is then an atomic box that the line has to make room for.

One more surprise belongs here. A word with no break opportunity, such as a long URL pasted into a card title, cannot be split, so it overflows the line box sideways. overflow-wrap: anywhere lets the browser break it where it must.

Padding and border always add up. Vertical margins in block layout often do not. When two block-axis margins touch with nothing between them, the browser keeps one margin the size of the larger and throws the other away. The rule was made for text: a paragraph with 1em of space above and below should be 1em from the next paragraph, not 2em. It still applies to every block in normal flow, including cards, sections and headings, and it is the single most common reason a gap on screen does not match the numbers in the stylesheet.

Margins touch in three situations. Two siblings, one under the other: the bottom margin of the first meets the top margin of the second. A parent and its first child: if the parent has no top border, no top padding and no inline content before the child, the child's top margin and the parent's top margin are the same edge, and the merged margin ends up outside the parent. The same goes for a parent and its last child at the bottom, where a set height or min-height on the parent also keeps them apart. And an empty block: with no content, padding, border or height, its own top and bottom margins meet, and it can collapse through to join the margins on either side of it.

Negative margins join in by arithmetic. The result is the largest positive margin plus the most negative one; if every margin is negative, the most negative wins. Anything that puts something between the two edges stops the merge: a border, padding, a line of text. So does a parent that starts its own block formatting context (display: flow-root is the clean way; the next topic lists the others), and so does leaving normal flow altogether. Flex items and grid items never collapse, and neither do floats or absolutely positioned boxes. Inline-axis margins never collapse in any layout.

Each column has a tinted background and side padding only. Its h2 has a 20 pixel top margin so the title does not touch the edge. On screen the tint starts 20 pixels lower than the other panels and the title sits flush against the top of the tint. The heading's margin has merged with the column's own top margin, because nothing (no padding, no border, no text) separates the two edges, and the merged margin is drawn outside the column, where the background does not reach.

This is the opening bug. The card was given width: 320px, padding: 16px and a 1 pixel border under the default content-box sizing, so its border box is 354. The column is 360 wide with 12 pixels of padding on each side, which leaves 336 for the cards. The card sticks out 18 pixels past that content edge and 6 past the column itself, and in the right-most column that overflow can give the whole board a sideways scrollbar.

Switching the card to border-box makes the number in the stylesheet the number on screen: 320. The better fix is to stop telling the card its width at all. A block box with width auto fills its containing block exactly, so the card becomes 336 wide in this column and still fits if the column is resized, or the board is opened on a phone where columns are narrower.

Cards were spaced with margin-block: 12px, and in a plain block column the bottom margin of one card and the top margin of the next collapsed into a single 12 pixel gap. Then someone made the column a flex container, to pin an 'Add card' button to its bottom. Nothing about the cards changed, yet every gap became 24 pixels. Flex items never collapse margins, so each card's bottom margin and the next card's top margin now add up instead of merging.

The fix is to give the job of spacing to the column. In a flex or grid container, gap puts a fixed space between items and none before the first or after the last, so the spacing no longer depends on which layout mode the parent happens to use. (gap does nothing in plain block layout; there, a margin on the children or the owl-style selector .column > * + * is still the tool.)