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

What a ride this discussion is; so many interesting thoughts.

A few points to note before I braindump: I'm the author of [gridless.design](https://gridless.design) and have spent a great deal of time thinking about grids in general. Ironically, there is a masonry-like layout on [my personal site](https://donnie.damato.design/); it uses the CSS column layout as I don't care much about the order, only the presentation. I've also read the [blog post by Rachel Andrew](https://developer.chrome.com/blog/masonry) regarding the alternative direction.

What I'll say is that I know from the decades of web design trends, I know the industry would benefit from the _basics_ of a layout such as being described above. I say basics because there are certainly more complicated possibilities (some outlined in the blog post at the top of the issue) that many other folks may never need. As @desandro mentioned, the typical use is equal columns, but from the further examples there probably isn't much stopping us from defining varied column widths because the logic of how to define columns has already been in use through CSS grid. I think there is value in considering the possibility of complex layouts but it also could be scope creep. I don't think I can speak to the later questions because I probably don't have the need for these additional complexities. I just used subgrid for the first time in [my latest site](https://wireframe.fm/) (the cards at the bottom) and I would have also been fine without it.

So thinking about the first question, where does the concept belong in the family of CSS properties that we could place it, I'm considering what it would mean to rethink layout entirely. _I'm not suggesting what I'm about to describe as an approach_, but instead using it to inform my thinking in the categorization of where this might live.

The way we describe flex vs grid is often 1D vs 2D layouts. However, grid does nearly behave like flex if it weren't for the column definitions. Children will wrap to the next line if allowed or be forced onto a single line. They both achieve this in different ways. Grid does this because of the number of columns and children, meanwhile flex will only allow wrapping when explicitly turned on. So I'm imagining a hybrid of both grid and flex, where children exist as taking up available space, packed densely until some definition comes in to influence how the packing occurs. If you only define columns, you'd get children to be sorted into the columns (in the layout we're describing here). If you only define rows, you get children sorted into the rows (a la flexbox) and if you define both, you get the grid. Children would be placed by writing mode such that all configurations will always set children left-to-right in LTR settings.

All that said and looking at both approaches, personally I'd like to see something like the following:

```css
.my-items {
  display: block | flex | grid | masonry;
  columns: repeat(auto-fill, auto);
  gap: 1rem;
}
```
I see no reason why we namespace `columns` where CSS has a history of only being valid with certain combinations of properties and values; such as `top` having no affect unless a `position` other than `static` is set or when poor CSS gradient syntax is written. If the CSS written is not well formed, then it doesn't do anything special. So in this case setting `display: flex;` doesn't provide any column definitions even if the `column` property is set. This is also related to our move from `grid-gap` to just `gap`, it is useful in other layouts.

I'm also avoiding the matter of people learning a new syntax. If someone wants it, they'll figure it out. We've gotten used to flexbox and grid after that. Whatever comes out of this we'll learn too. It's more important that this can support a need; even if the syntax isn't precisely what we might have been expecting.

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


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

Received on Wednesday, 1 May 2024 02:54:46 UTC