CSS Masonry Layout

[fantasai]

こんにちは TAG-さん!

I'm requesting an early TAG design review of masonry layout in CSS.

Masonry layout creates grid-based tracks in a single axis, and stacks items tightly in the other, creating rows or columns but not both. It is currently drafted into https://www.w3.org/TR/css-grid-3/ with two possible syntax options: a grid-based syntax that uses a keyword to relax alignment in the stacking axis, and an independent syntax that uses a blend of flex and grid concepts with a new set of properties. The arguments in the debate center over a) which is easier to learn for authors and b) how might this decision impact possible future developments in one or both models (or CSS in general).

I'm opening this issue to ask the TAG to schedule a review of the spec in general and of the syntax question specifically. We are currently collecting feedback, and are hoping to have a CSSWG discussion on this question in late October / early November. We will update this issue as input comes in.

• Explainer¹: See spec introduction for a basic intro and Jen's blog post for more extensive examples
• User research: See other links.
• Security and Privacy self-review²: Nothing interesting to report
• GitHub repo: CSSWG repo
• Primary contacts:
  • Elika J Etemad (@fantasai), Apple, editor
  • Tab Atkins-Bittner (@tabatkins), Google, editor
• Organization/project driving the design: Mozilla, Apple, Google
• Multi-stakeholder feedback³:
  • Chromium comments: Positive in general; started implementation. See also:
    • Proposal for alternative model and in particular this comment from Tab
    • https://developer.chrome.com/blog/masonry-syntax
  • Mozilla comments: Positive in general; prototyped initial draft. No position posted yet (afaik) on the open syntax debate, but they proposed the original grid-based syntax in 2020.
  • WebKit comments: Positive in general; usable experimental implementation in progress. See also:
    • https://webkit.org/blog/16026/css-masonry-syntax/
  • Developer/designer comments:
    • See comments in https://github.com/w3c/csswg-drafts/issues/10233 ; https://github.com/w3c/csswg-drafts/issues/9041 ; note there's some bias in where authors posted comments, since one was linked from the WebKit post and the other from the Chrome team post.
    • This blog post does a deep dive into examples: https://ishadeed.com/article/css-grid-masonry/

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): CSSWG
• The group where standardization of this work is intended to be done ("unknown" if not known): CSSWG
• Existing major pieces of multi-implementer review or discussion of this design:
  • Index of individual issues grouped under Chrome's uber-issue
  • CSSWG resolution adopting mixed track sizing
• Major unresolved issues with or opposition to this design: Syntax and direction of future development being integrated with, or segregated from, CSS Grid Layout.
• This work is being funded by: Mozilla, Apple, Google.

You should also know that...

• Some of the key arguments in the early syntax debate were resolved by the above-linked resolution to adopt mixed track sizing under both options, with some notes/restrictions wrt performance, so if you're doing archaeology keep that in mind.
• We're hoping to schedule CSSWG discussion of the syntax and overall direction of this module in 2-4 weeks or so. Let us know how we can accommodate the TAG.

[jyasskin]

This comment is just from me, without having consulted the rest of the TAG yet.

I see that we have a compelling description of the use case (Yay for solving this problem!) and a pair of documents advocating for the alternative syntaxes. It's not clear whether both sides agree with the claims in each document and just weigh them differently, or also disagree about some of the factual claims. I'm not confident that the TAG will know enough about the design space to figure out what facts are true, although we may be able to help weigh tradeoffs.

Would it be possible for the two sides to get together and produce a consensus document that describes the disagreement and points out the different values that the TAG should be weighing?

[rachelandrew]

As the author of the two Chrome posts on the subject, I'd be happy to help create a consensus document. I also have collected developer feedback on the issue.

[fantasai]

I'm happy to work with @rachelandrew on this.