Re: [csswg-drafts] [css-grid-3][masonry] Masonry Syntax Debate (#11243)

Now that I've had more time to consider the opinions raised in our call on Wednesday – and particularly the TAG review which @LeaVerou shared – my mind has changed and I have swayed towards the 'Just use grid' option. I'll explain why.

https://github.com/w3ctag/design-reviews/issues/1003#issuecomment-2489688718

The TAG viewpoint set us a new north star to aim for where _all_ layout methods that do a '2D arrangement of children' become more unified and easier for authors to declare:

> Overall, we think masonry, grid, and wrapping-flexbox should be incorporated into a unified set of properties.

This argument was particularly compelling to me (emphasis added):

> 4. It was argued that the grid-independent syntax makes things easier if the properties need to [diverge in the future](https://developer.chrome.com/blog/masonry-syntax#other_considerations). We think **that is a drawback of that syntax, not a feature.** Even if the WG selects a syntax like the grid-independent one, **it should work hard to ensure that the properties diverge as little as possible in the future,** even if some masonry properties initially appear not to have an obvious behavior for other display modes. It would be even worse to evolve subtle variations in patterns that otherwise appear to match, for example by forgetting to apply a new grid keyword to the parallel masonry property.

This argument trumped my main concerns around how we might want the syntax to diverge. The argument also supported [the vision that the WebKit team gave us at the end of their blog post about a possible future where we could even somehow use the grid properties on flow layouts.](https://webkit.org/blog/16026/css-masonry-syntax/#a-possible-future-feature)

And then the TAG review goes on to talk more broadly about layout syntax.

> We urge the WG to explore ways to unify these so that authors can port more knowledge from one to the other (even if they are implemented as separate code paths internally). For example `grid-auto-flow`, `flex-direction`, `masonry-direction`, and `masonry-fill` all control the same stylistic aspect from an author pov and it seems that they could be more unified to some degree.
> [...]
> These patterns blur the line we've been assuming between 1-d and 2-d layout, and the WG may need to solve the problem by leaning into a continuum between those two options. It would be ideal to find a set of properties that can be used to build all of these layout patterns, instead of [potentially overfitting](https://medium.com/design-bootcamp/overfitting-and-the-problem-with-use-cases-337d9f4bf4d7) to just masonry layouts.

## In conclusion

On behalf of the BBC, I am happy to support the "Just use grid" syntax to move the proposal forward.

However, the TAG review has set out a wider vision for shorthands or other more generic syntaxes for defining layouts. Would it be helpful, as part of this issue, to start blue-skying those, just to help the debate along? I would be interested to see any proposals.

For example, the fact that we can now use `gap` in flex layouts and `align-content` in grid, flex _and now flow_ layouts has been a game changer. It would be great to see how some of the `grid-*` properties could be made more generic. Like @kizu said, 'It is true that authors rarely use the grid shorthand, and that means that we should look into how we could improve it for all the cases.'

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


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

Received on Friday, 6 December 2024 16:31:51 UTC