Why? What's the downside to reusing grid-column-template or whatever for the CSS Masonry spec?
Why? What's the downside to reusing grid-column-template or whatever for the CSS Masonry spec?
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
> 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