[mvonballmo]

A "row-less" grid fits very well in the current CSS Grid specification, in that it can reuse the very powerful column-definition property as well as sub-grids. Their examples very convincingly show how orthogonal these features are.

Mostly, you just write grid-row-template: masonry and everything else just works with it. This is nice. It doesn't become harder to use the grid layout than it already is IMHO.

The drawback is mostly for browser-engine authors, for whom the bar for "fully supports CSS Grid" will be set even higher. They also mention that it might avoid "performance traps" where an implementation that needs to support all features of grid might be slower at some parts of grid layout than it would be if the specification were simpler.

If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame.

[nightpool]

> If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame.

Why? What's the downside to reusing grid-column-template or whatever for the CSS Masonry spec?

[krsdcbl]

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

[beardedetim]

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

[datavirtue]

That would be too simple and clean.

[afiori]

> 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