Re: [csswg-drafts] [css-grid-3][masonry] item-flow row vs. column in masonry layouts (#12803)

I was reminded over lunch that, in #12804, we resolved that the direction of shorthanding had to go from the item/flow-* properties to the layout-specific ones. That is, `flow-*` are shorthands, `flex-*`/`grid-*` are longhands. I had assumed it was the opposite, and `flow-*` would be the source-of-truth longhands that the layout-specific ones would shorthand into. :(

This opposite direction is particularly problematic here. All proposals require some *existing* `flex-*` and `grid-*` longhands to become shorthands, with new more-specific longhands. [My proposal](https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3519260414), by dividing up the `flow-*` properties further, would require *even more* atomization. It also means that we either need to *entirely* re-use `grid-*` properties for Masonry, or invent some new Masonry-specific properties; any additional layout modes we define need to either be "some type of Flexbox", "some type of Grid", or define their own new set of layout-specific properties.

This then raises the question: is it really worth pursuing this? The *entire point* of following the TAG's feedback here was to reduce the number of layout-specific properties that we need to create as we add new layout modes; we could instead just use the generic set from now on. But for various Reasons, we end up having to create *more* layout-specific properties, and as we add new layout modes, we'll *still* need to create layout-specific properties for them that the generic properties can shorthand to! 

The TAG feedback was well-intentioned, but we've explored this proposal into the dirt by this point. We end up needing to name things in an overly-generic fashion that won't help authors, and still create new layout-specific properties, which negates the entire purpose of the exercise in the first place!

------------

So, the alternative proposal to all of this trouble is: just reject the TAG feedback. This would mean:

* Flexbox gains 'balance' via some `flex-*` property.
* If/when we want to add "dense" and "tolerance" to Flexbox, we do so with `flex-*` properties again.
* Grid gains nothing, it's perfect as-is.
* Masonry gets its own set of properties that are well-designed for it. Probably:
 * `grid-lanes-flow: [ row | column | row-reverse | column-reverse ]  && dense?` (`row`/`col` sets the track orientation, `*-reverse` reverses the "flow direction" *across* those tracks'; `column-reverse` is "waterfall" filled right-to-left.)
 * `grid-lanes-stack: normal | stack-reverse` (when multiple items are in a track, how do they stack; for columns, top-to-bottom or bottom-to-top)
 * `grid-lanes-tolerance: <length-percentage> | infinity` - as currently defined
* We can still name Masonry whatever we want. I assumed `grid-lanes` here.
* We can still reuse the `grid-template-*` properties for Masonry if we want. Or we can give Masonry its own set of template properties, to avoid having to define what `repeat(auto-fill, auto)` means for Grid, which we still don't have a meaningful answer for.

Now, `grid-lanes-flow` looks similar to `flex-flow` or `grid-auto-flow`, but is not bound to interpret its keywords exactly the same; it can do the "correct" thing for itself. Masonry can define concepts for itself, like "tolerance", without forcing us to immediately make a decision for *every existing layout mode* about whether they have "tolerance" at all, and how it works. I think we've come to the point where we need to accept this is the correct solution.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3520236111 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 November 2025 06:20:50 UTC