Re: [csswg-drafts] [css-grid-3] Designer/developer feedback on masonry layout (#10233)

I feel like I'm in the minority with @tryoxiss, who [has pointed out](https://github.com/w3c/csswg-drafts/issues/10233#issuecomment-2087442341) that it's possible to have masonry layouts that have *neither* fixed rows *nor* fixed columns. I've read through all of the comments and if there are any others noting this, they're few and far between, despite it being what I'd consider to be a "true" masonry layout. In fact, I like the distinction they make between masonry and waterfall, because those are two fundamentally different layouts that just happen to achieve a somewhat similar result if you don't look too closely. I get the sense that the responses so far have been kind of stuck by the current limitations of masonry implementations, stymieing the potential of this feature to break free of those limitations.

If "masonry" is *only* ever defined as "defined rows, undefined columns" or "defined columns, undefined rows," then sure, put it into grid, but if there's *ever* the possibility of allowing the "fit them together like a jigsaw" style that tryoxiss illustrates, then shoehorning it into grid is shortsighted, in my opinion, because you end up throwing out *most* of grid's features, instead of just some of them to make this layout, and you inhibit your ability to add features that would pertain to waterfall or masonry, but not to grid, without having to make concessions that those additional features are just invalid with certain other combinations. In light of that, it seems better all around to separate them -- it's clearer for the front end developer what display paradigm an element is working under and more predictable for what does and doesn't work, and it doesn't take as much overhead for implementers to figure out all the combinations that do and don't work for directives that are otherwise valid for that display paradigm.

Now, if it is part of grid, it does create a rather obvious solution to the question raised earlier of "what happens when grid-template-rows and grid-template-columns are both set to off?" At that point, it would/could be the "true" masonry, whereas when only one or the other is off, it creates a waterfall layout. ...But at that point, if we turned off both rows and columns, are we even talking about a grid anymore? Isn't the whole purpose of a grid...rows and columns? Not having one is stretching it, in my opinion. Discarding both breaks it entirely.

To me, having grid, waterfall, and masonry as separate options for `display` makes the most sense. `display` concerns itself with content flow, both of the element in relation to its siblings (block, inline-block, inline) and in relation to its contents (grid, flex, table), while the individual settings determine the details of how the elements flow, without significantly changing the overall flow model set by `display` -- spanning a row or column doesn't mean the element is no longer working within the context of a grid or table, for example. Waterfall and masonry are different flow models from grid and flexbox, for the aforementioned reasons, and thus warrant their own options on `display`.

(tl;dr - +1 for `display: masonry`)

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


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

Received on Wednesday, 25 September 2024 19:40:52 UTC