my thoughts exactly - i think this points to a possible naming issue, since "masonry" is a relatively vague alias that does not really describe the underlying layouting logic, it just became ubiquitous enough for people building webstuff to understand because of that one jQuery plugin back in the days.

A better approach might be to lean on the "grid" naming, but still silo it off via an own display directive (a bit like "block" and "inline-block" have shared properties, but also mutually exclusive behaviours)

So maybe an own `display: flex-grid;` could be an interesting solution?

This separate layout mode would avoid "result-specific" nomenclature like "masonry", and could lean on both flexbox & grid to achieve that look: - using `grid-auto-flow` to set a "masonry axis" & distribution logic - using _either_ `grid-template-columns` or `grid-template-rows` to specify the "lanes" - and to make my frankensteinian display-mashup even worse (or genius! for you to decide), the grid items could in turn abuse `flex-grow, flex-shrink, flex-basis` to control their height/width within the main "masonry" axis

I really like this concept of `flex-grid` because that's exactly what this display would be.

That would be too simple and clean.

> And yes, while making CSS Grid more complex will make it harder to extend in the future, we believe there’s an advantage to having these two types of grid layouts intertwined. This way the CSS Working Group will always define all new additions for both modular and columnar grids. There won’t be something added to display: grid that will be left out of display: masonry, or vice versa. For example, many developers want CSS Grid Level 4 to provide a mechanism for styling grid areas and grid lines — perhaps a way to add a background color to a track, or create a rule line in a gap. It’d be great to ensure that will work for both modular and columnar grids from Day 1.

> By using subgrid, we can put the year and catalog number on the right of each card — and line up this data for one painting with the same data for the other paintings.

The downside is that all the parts of grid that might be useful in masonry would have to be duplicated in slightly different ways.

This together with the fact the the only two current implementations use display: grid

If it is possible to make them perfectly compatible then the main negative side