Layout: Float, Flexbox & Grid

Applying float: left or float: right to an element takes it out of normal document flow horizontally and pushes it to one edge of its containing block. Unlike position: absolute, a floated element is not removed from flow entirely: surrounding inline content (text, inline images) still flows around it, wrapping to fill the remaining horizontal space — this text-wrapping behavior is float’s original purpose and the one thing neither flexbox nor grid replicate.

When multiple sibling elements are all floated the same direction, they line up next to each other, wrapping to a new row once a row’s combined width exceeds the container’s width. This is how a float-based product grid works — each product div floats left at a fixed percentage width:

A floated element must also be given an explicit width (in pixels or a percentage); unlike a block element in normal flow, a float does not automatically expand to fill the container’s width.

Because floated children are taken out of flow, a container whose only children are floated collapses to zero height — it has nothing left in normal flow to size itself against. The simplest fix is to make the container establish a new block formatting context:

overflow: hidden has the side effect of establishing that new formatting context, which forces the container to expand and enclose its floated children — but as a side effect it also clips any content that overflows the container’s box, which can be a problem for elements like tooltips or dropdown menus. Two alternatives avoid that trade-off:

Float-based layouts have no built-in responsiveness: a fixed pixel or percentage width on each floated item does not itself adapt to the viewport. Making a float layout responsive means changing the float and width declarations inside a media query — for example, dropping the float entirely and stacking items in a single column below a breakpoint (see Media queries below). Float layouts also have no special scrolling behavior of their own; the container scrolls like any other block box if its content overflows (see Scroll behavior: overflow and scroll-snap), and overflow: hidden used purely for float-clearing has no scrolling implication since it establishes a formatting context without necessarily clipping any actual overflow.

Turning an element into a flex layout only requires one declaration on the parent:

The element that receives display: flex (or inline-flex) becomes the flex container; its direct children automatically become flex items, laid out along a single line by default. flex-wrap: wrap allows items to wrap onto additional lines once they no longer fit:

Every flex container has two axes: the main axis, along which items are laid out and spaced (controlled by flex-direction and justify-content), and the cross axis, perpendicular to it (controlled by align-items/align-content). flex-direction: row (the default) makes the main axis horizontal; switching to flex-direction: column rotates the main axis to vertical — and with it, every main-/cross-axis property’s effective direction, without changing any other declaration.

This distinction matters because most flexbox properties are named for the axis they act on, not for a literal screen direction — justify-content: center centers items along whichever axis is currently "main."

Flexbox’s flex-wrap/flex-grow/flex-shrink already provide a form of built-in responsiveness — items reflow onto new lines or resize proportionally as the container shrinks, without a media query. A common pattern layers a flex-direction change on top, switching a horizontal toolbar to a stacked column below a breakpoint:

For scroll behavior, a flex container with overflow-x: auto and flex-wrap: nowrap turns into a horizontally scrollable row (a common carousel pattern); pairing it with scroll-snap-type/scroll-snap-align makes that scrolling snap to item boundaries instead of stopping at an arbitrary offset (see Scroll behavior: overflow and scroll-snap).

As with flex, one declaration on the parent activates the layout, and its direct children become grid items:

Unlike float or flexbox, grid items do not need an explicit width (or flex-basis) at all for simple cases — the column tracks defined on the container already determine each item’s size.

grid-template-columns/grid-template-rows define the size of each column/row track. Besides fixed lengths and auto, grid introduces the fr ("fraction") unit, which divides any remaining space proportionally — similar in spirit to flex-grow, but for the whole track rather than one item:

repeat() avoids writing out repetitive track lists, and minmax() gives a track a size range instead of a fixed value — combined with the auto-fit keyword, this produces a card grid that reflows its column count automatically as the viewport resizes, with no media query at all:

Every track boundary is a numbered grid line (column lines and row lines, both starting at 1), and items can be placed by referencing those line numbers directly with grid-column/grid-row:

Lines can also be given names when the tracks are declared, making later placement rules self-documenting:

For whole-layout composition, grid-template-areas names cells rather than lines, laying the template out as an ASCII grid that mirrors the resulting page visually — each item then just declares which named area it belongs to via grid-area:

The diagram above is exactly this sidebar/header/main/footer layout: sidebar spans grid line 1 to line 4 on the row axis (three row tracks), while header, main, and footer each occupy one row track in the second column.

Grid’s alignment properties mirror flexbox’s, but apply across two axes at once rather than one: justify-items/align-items position an item within its own cell (justify-items along the row axis, align-items along the column axis), while justify-content/align-content position the whole track grid within the container when the tracks don’t fill it completely — analogous to justify-content in flexbox, but along both axes. Items not explicitly placed fall into the implicit grid, whose auto-generated track sizes and placement direction are controlled by grid-auto-rows/grid-auto-columns/grid-auto-flow.

repeat(auto-fit, minmax(…​)) (shown above) is grid’s signature responsive pattern: the browser recalculates how many tracks fit as the viewport resizes, with no media query. grid-template-areas is also commonly redeclared entirely inside a media query, reflowing a whole page layout at a breakpoint (for example collapsing the sidebar/header/main/footer layout above into a single stacked column below a given width). For scroll behavior, overflow on the grid container plus scroll-snap-type produces a snapping grid or filmstrip in exactly the same way as flexbox (see next section); CSS subgrid (grid-template-columns: subgrid) is a further, newer refinement letting a nested grid’s tracks align to its parent’s, though browser support should be checked before relying on it.

@media conditionally applies a block of CSS based on characteristics of the viewport (most commonly its width), letting a layout redeclare its float/flex/grid properties at defined breakpoints:

Container queries (@container) apply styles based on the size of an ancestor container rather than the viewport — useful when a component (a card, a widget) needs to adapt to the space it happens to be placed in, independent of the overall page width. A container-type declaration first opts an element in to being queried:

This is particularly relevant to flex and grid items, since the same card component can end up in a wide single-column area or a narrow grid track depending on where it’s placed, and a container query lets it adapt to either without the parent layout needing to know about it.

Layout width alone doesn’t make images responsive — the browser also needs to be told which image file to fetch for a given size, so it isn’t downloading an oversized image into a narrow flex/grid item. srcset plus sizes lets the browser pick the best-matching resolution from a set of candidates:

<picture> goes further, letting different image files entirely (not just resolutions) be served per breakpoint or format, with the final <img> as the fallback:

vh/vw do not account for mobile browser chrome (address bars, toolbars) that can appear or retract while scrolling, which makes a 100vh element jump in size as that chrome shows or hides. Newer viewport units address this directly: svh/svw ("small viewport") assume browser UI is fully expanded, lvh/lvw ("large viewport") assume it’s fully retracted, and dvh/dvw ("dynamic viewport") track whichever is currently visible, clamped between the two:

Any container — floated, flex, or grid — becomes scrollable once overflow (or the axis-specific overflow-x/overflow-y) is set to auto or scroll and its content exceeds its box. scroll-snap-type on the scrolling container, combined with scroll-snap-align on its children, turns free scrolling into a snapping experience that stops on item boundaries — the standard technique for horizontal carousels and full-screen sections alike:

Scroll position can also drive animation directly, without JavaScript scroll-event listeners, via animation-timeline: scroll(): the animation’s progress is tied to the scroll offset of its nearest scrolling ancestor instead of elapsed time, which is how a scroll-linked progress bar can be built purely in CSS: