An easy-to-use method for implementing masonry layouts has long been sought for by the web developer community. It has been difficult to create these aesthetically dynamic grids using only CSS, thanks to Pinterest and related designs. The Chrome team contends that this strategy might not be the best one, despite recent recommendations that call for masonry capabilities to be added to the CSS Grid Layout specification. Here are some reasons why we think masonry should have its own layout technique and some potential advantages for developers.

The Case Against Adding Masonry to CSS Grid

1. Performance Concerns

CSS Grid and masonry layouts handle item placement in fundamentally different ways:

• CSS Grid: All items are placed before layout, allowing the browser to calculate exact track sizes and placements.
• Masonry: Items are placed as they are laid out, requiring dynamic calculations that can lead to significant performance issues when mixing fixed and intrinsic track sizes.

Consider a grid with mixed track definitions like grid-template-columns: 200px auto 200px. With masonry, the browser must pre-layout every item in every possible configuration, creating exponential complexity in large grids. This is especially problematic when using advanced features like subgrids.

To avoid shipping a layout method with such inherent limitations, we propose a solution that separates masonry from CSS Grid.

2. Specification Complexity

Merging masonry into the grid specification introduces inconsistencies that conflict with the core principles of formatting contexts:

• Alignment Properties: Grid supports six alignment properties, but masonry would only use a subset, like flexbox.
• Placement Properties: Grid has four placement properties (e.g., grid-column-start), while masonry would need only two.
• Track Sizing: Certain patterns like grid-template-columns: repeat(auto-fill, max-content) make sense in masonry but must remain invalid in grid.

Introducing these discrepancies increases the cognitive load for developers, as they would need to remember which features work in which context. This fragmentation could lead to confusion and errors.

The Proposal: Masonry as a Separate Layout Method

Instead of bundling masonry with CSS Grid, we advocate defining it as a standalone layout method using display: masonry. This approach retains all the flexibility developers love about grid while avoiding the pitfalls outlined above.

Example

Classic Masonry Layout

A simple masonry layout with equal-sized columns can be achieved with:

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

Mixed Track Sizes

For layouts with alternating narrow and wide columns:

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
  gap: 1rem;
}

Auto-Sized Tracks

Allow tracks to auto-size based on content:

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
  gap: 1rem;
}

Spanning and Placement

Enable items to span multiple tracks:

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
}

.span-2 {
  masonry-track: span 2; /* spans two columns */
}

.placed {
  masonry-track: 2 / 5; /* covers tracks 2, 3, and 4 */
}

Benefits of a Separate Masonry Layout

Clarity: Developers can use masonry without worrying about the nuances of CSS Grid compatibility.

Flexibility: All grid-like features remain available without introducing new constraints.

Future-Proofing: A dedicated masonry specification ensures consistent behavior across browsers and avoids unnecessary complexity.