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

> In @fantasai's proposal, grid-auto-flow is set to normal, not column.

Yes, that is true, her example sets `normal`, but in my example, I am _intentionally_ set it to `column` to show that would _also_ be equivalent, and that is the part that I find problematic.

> WebKit's implementation was pretty straightforward. Regardless though, the author benefit of having fewer properties to work with outweights the implementation benefit claimed here (which I dispute, because there is implementation complexity in adding new properties too)...

I would be curious to see what sorts of stress tests and logic is being used, because I can say for certain that adding a simple two-keyword property will be much simpler complexity as compared to the magic of determining which direction wins and which properties need to be overridden as a result of 4 different property sets _after_ the cascade in Chromium. I should also note that because this has to happen after the cascade, the implementation complexity to track the ordering of properties would apply not only to grid-lanes, but to grid, as well, which makes the added complexity a larger burden, even when not needed.

And implementation complexity is not the only reason that I would prefer to have a single source of truth for the direction. There are also strong reasons from an authoring perspective why this would provide a clearer experience.

For example, as I understand @fantasai's proposal (and this would also be possible to hit in @tabatkins's proposal), the following two CSS blocks would produce 2 very different layouts.

```
display: grid-lanes;
grid-template-rows: 100px 100px;
grid-auto-flow: row;
```
This example would produce 2 **columns** of 100px (because `grid-auto-flow: row;` is set last and forces us to override the initial track definition and apply it to the column direction.)
```
display: grid-lanes;
grid-auto-flow: row;
grid-template-rows: 100px 100px;
```
This example would produce 2 **rows** of 100px (because `grid-template-rows: 100px 100px;` is set last and forces us to override the initial `grid-auto-flow` definition from `row` to `column`.

Being able to set the same property-value sets, but getting significantly different layouts when adjusting the order they are set in could lead to a lot of author confusion, and would make it more difficult for an author to debug when things aren't working as they expect.

In my proposal, the ordering of properties doesn't matter. The following two examples would be equivalent since even though `grid-template-rows` are set, we create a column layout (with a track definition of `none`) because `grid-lanes-orientation` is set to `column`, and that is the source of truth, no matter what the other properties are set to.

```
display: grid-lanes;
grid-lanes-orientation: column;
grid-template-rows: 100px 100px;
```
is equivalent to:
```
display: grid-lanes;
grid-template-rows: 100px 100px;
grid-lanes-orientation: column;
```

Although authors don't get the magic of `grid-template-rows: 100px 100px;` switching to be the definition of `grid-template-columns` in this proposal, I'd argue that it is much easier to debug why they got the wrong layout in this approach, vs in the example using `grid-auto-flow` above.

As such, sometimes special CSS magic can lead to lesser authoring experiences, and I think this is an example where that would be true.

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


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

Received on Wednesday, 3 December 2025 15:43:29 UTC