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

I've spent some time thinking about this before commenting because I think there are good arguments to be had from both sides (adding it to Grid vs. `display: masonry` (or whatever it ends up being called), and my main thoughts are:

- We do need this
- It should be a part of the grid spec
- I'm leaning toward `grid-template-rows: off` now that I've had time to digest that idea

## Where I'm coming from
I've seen some people pointing to potential performance issues based on repaints and layout shifts, and other things on the technical side of how it will be implemented. I'm simply coming in on this from a "in an ideal world, this is how I would like to use it, and how I think, from my experience helping people learn CSS, will be the easiest for them to pick up."

## We do need this
1. We wouldn't have multiple JS solutions for this type of layout unless it is something that people want to create.
2. I get a fair amount of emails and DMs asking me how to create this type of layout. It is also something that's frequently asked in my Discord community. The answers are always "either use columns if you don't mind the content flowing vertically, or use a JS solution."
3. Perhaps most importantly, we already have CSS-only solutions for other things we've traditionally used JavaScript to solve, such as scroll-driven animations. While those are *amazing* and I'm very happy to have them, I don't understand how scroll-driven animations can be seen as something that is needed in CSS, but controlling a layout is something we're okay having to rely on JavaScript for.

## It should be a part of the CSS Grid spec

I feel like it should be a part of the Grid spec, rather than creating a new display type. 

### "Most uses cases" shouldn't be good enough
Several people have pointed out that `display: masonry` will cover *most* of the potential use cases of what people will want. I agree with that. However, there will be times when we want/need to do more, whether it's a narrower column here, a span there, or the use of subgrid somewhere. 

If we close off some doors because this other method covers most use cases it seems like a missed opportunity to me (subgrid being a big one for me, as I don't see how it could be compatible in any way if we break it into its own display type).

#### Caveat
One thing I haven't understood is why a `display: masonry` would have to be more limited than grid, but it seems that's the case, which is my primary reason I wouldn't want to see it go that route. If it has it's own version of subgrid, is able to have uneven columns (or rows, if you have a horizontal masonry), and all those types of column/row definitions we can currently do with Grid, I'm far less opinionated on which direction we go.

My main worry is, we don't know what people are going to do with this, but people *will* do things with it that we can't anticipate. The more feature rich it is, the more creative people will be with it. 

We haven't seen layouts that take advantage of these all of thse things because we don't really have a way to create them now, even with the existing JS solutions. Those often limit you to even columns, and there is no way to have things like subgrid or other grid features we have now.

### It fits well with common uses of grid
This new proposal is almost an in-between between flexbox and grid, so I do understand the argument for having a different display value, but from what I see, a large majority of grid layouts don't define rows to begin with. Instead they rely on the implicit creation of them while explicitly defining the columns. 

To be able to toggle between the implicit rows we have now to a masonry style layout with a `grid-template-rows: off` (or `waterfall` or `masonry`) feels like the simplest approach when writing the CSS. 

### It's (potentially) easier to learn
As someone who spends most of my time teaching CSS, I feel that it's a lot easier to introduce the layout as a small addition to Grid rather than to have to jump into a new display type, even if there are many similarities.

I realize that there will potentially be more to it all than simply toggling our rows on and off, but like a `display: masonry` will cover a large majority of use cases, simply defining columns and then changing the `template-rows` will cover those same use cases. 

In my experience of helping people learn CSS and seeing how they progress through it, this feels like the easiest way for a learner. You learn how to define columns and rows then simply how "let the rows do their own thing" becomes a natural progression, rather than an "alright, now take everything we've learned, and we're going to bring it to this other display type".

This isn't a big deal by any means, but imo, the less friction when learning something, the better.

From there, it definitely has the potential to get more complicated, but that doesn't matter which syntax or display type we go with, at one point, if you want to get past the basics of how something works, you need to learn more about it. 

While there might be some values that might only be available after changing the behavior of our rows (`masonry-auto-flow`, for example), is that more complicated than understanding the difference between a `top: 0;` between the different `position` values we have, and when containing blocks do or don't come into play? 

To me, with `justify-tracks` being only part of this spec will be just as confusing as to why `justify-items` is only available in Grid and not Flexbox. I don't see why it would be more confusing if the new properties "unlocked" with a `grid-template-*` value, rather than a `display` value.

There would be confusion on why certain things work in grid columns and not masonry columns as well, even if they have different display types. People see all of these as "layouts", and when it comes to setting up columns and placing things in those columns, the same questions and confusion will happen either way.

### Sidenote on `columns` or `masonry-columns`
If, in the end, a `display: masonry` (or other name) is the direction this goes, I don't understand the idea of going with `columns` or `masonry-columns`. 

Don't get me wrong, the names make sense, but we've just spent years training people to use `grid-template-columns` and `grid-template-rows`, I feel like a `masonry-columns` then will just add another inconsistency to CSS.

My guess here is we wouldn't need a `masonry-column` to explicitly place and element in a column, so there won't be the confusion of `masonry-column` and `masonry-columns` (though, why not? I could see wanting to have one element in a specific column and letting the rest flow). 

I get we all want to write less characters, but if it's going to work even a little similarly to `grid-template-columns` (and I'm guessing the most common use case will be a `repeat(auto-fit, minmax(250px, 1fr))` or something like that, then could we simply make it `masonry-template-columns` and avoid even more confusion? 

_"Yes, when it's a grid, it's a template column, but when it's a masonry layout it's just a column... no, there isn't really a difference in how they work, we just named them differently like that, so try to remember it correctly_." 🤷

If I'm misunderstanding why we'd go with a different name here, please let me know!

## What should we call it?
From all the questions I see about layouts like this, I've noticed that people have *no* idea what to call it and have trouble searching for solutions because of that, so I don't think there is a "wrong" answer here. If all you're doing is wanting to make some simple columns, it's not like `flex` is obvious either.

That said, as an added bonus, I do feel like keeping it in the grid spec also makes it easier to come up with a less confusing name.

When I first read of the idea of `grid-template-rows: off` I didn't particularly like it, but the more I've thought about it, the more I do think it fits, and is probably the easiest way to understand what it means for a lot of people who are coming in with zero knowledge about what something like this is called, since, in a sense it will act as a toggle.

Coming from the perspective of a teacher, I see this being the one that gets the most head-nods when explained, and this can be reinforced with a quick opening of the dev tools with a grid inspector and showing how things don't live on rows anymore, whereas a `masonry` or `waterfall` then has to be accompanied by a slide that shows some imagery to help people understand why we called it that. 

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


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

Received on Monday, 29 April 2024 14:59:03 UTC