Masonry Layout: Packing Content Without Wasted Space

CSS Grid's row model is intentionally strict and predictable: every item placed in a given row shares that row's height, and that height is determined by the row's tallest item. This is exactly the right behavior for tabular, form, or dashboard layouts where alignment across a row matters — but for a photo gallery or card feed with wildly varying natural heights, it produces visually awkward gaps beneath shorter items.

This isn't a bug or a limitation to work around with clever grid-template-rows values — it's a fundamental property of how Grid's row-based algorithm works. True masonry requires an entirely different placement algorithm, one that tracks column heights independently rather than committing every item to a shared row.

Masonry layout tracks the current accumulated height of each column independently, and places every new item into whichever column is currently the shortest, then updates that column's tracked height. This is precisely the algorithm behind Pinterest's board layout, and it's what the proposed native grid-template-rows: masonry value implements directly at the CSS engine level, keeping items in their original document order while still achieving tight, gapless packing.

A subtlety worth understanding: true masonry (as implemented natively or by dedicated JS libraries) preserves DOM order — item 4 always comes after item 3 in the document, even if it visually lands in a different column. This differs from some naive 'shortest column' implementations that reorder the DOM itself, which can break both keyboard tab order and the natural reading order for screen readers.

Native masonry (grid-template-rows: masonry) is a genuinely elegant solution, but as a newer proposal its cross-browser support isn't yet universal — check current compatibility data before relying on it without a fallback for your specific audience. Two practical alternatives exist today: CSS multi-column layout (columns: 3), which is very broadly supported and produces a visually similar packed effect, though it fills columns top-to-bottom in source order rather than shortest-column-first, which can look subtly different for very uneven content; or a small, well-tested JavaScript masonry library for projects that need pixel-perfect, shortest-column packing with guaranteed support everywhere.

The practical decision usually comes down to how tightly-packed the visual result needs to be, and how broad the target browser support requirement is — multi-column is often 'good enough' for many real designs, while JS libraries remain the safe universal choice for cases where a Pinterest-exact result is a hard requirement.

The Pinterest Layout, Without A Grid Gap. A regular grid lays items out in strict rows — every item in row two starts below the tallest item in row one, leaving gaps under shorter neighbors. Masonry layout instead packs each new item into whichever column currently has the least content, like bricks settling into the shortest gap, eliminating that wasted space entirely.

Why Regular Grid Rows Leave Gaps. In a standard grid, every row's height is determined by its tallest item, and every item in that row shares that same row boundary — a short item simply leaves empty space below it before the next row begins. This is correct, predictable grid behavior, but it's visually wasteful for content like photos or cards with wildly varying natural heights.

Why Regular Grids Gap. In a standard CSS Grid, why does a shorter item in a row leave visible empty space beneath it?

• →It's a layout bug that should be fixed with padding
• →Every item in a row shares that row's height, which is set by the row's tallest item
• →It doesn't actually happen in a normal grid

Masonry Packs Into The Shortest Column. True masonry layout tracks the current height of each column independently and places each new item into whichever column is currently shortest, rather than locking items to strict shared rows — the defining visual signature of a Pinterest-style board with no wasted vertical space.

Masonry Placement Logic. How does masonry layout decide which column a new item goes into?

• →It always cycles to the next column in order, ignoring height
• →It places the item into whichever column currently has the least accumulated content height
• →Column placement is effectively random

Today's Practical Implementation Options. Native grid-template-rows: masonry is a genuinely promising proposal, but as of this lesson its cross-browser support isn't universal, so production masonry layouts today typically still use either multi-column layout (column-count, which produces a similar but not identical visual effect) or a small amount of JavaScript for true item-order-preserving masonry.

Practical Masonry Today. Why might a production project use column-count (multi-column layout) instead of native masonry today?

• →Because it produces a visually identical result with no trade-offs
• →Because native CSS masonry doesn't yet have universal cross-browser support, and multi-column is widely supported
• →Because native masonry syntax doesn't actually exist

Masonry Layout Understood. You now understand exactly why regular grid rows leave gaps that masonry avoids, how the native masonry proposal packs items into the shortest column, and which practical implementation approaches are reliable to ship in production today given current browser support.

Build A Masonry-Style Layout. column-count splits content into multiple flowing columns, a stable way to approximate masonry layouts.