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 [css-grid-3] Designer/developer feedback on masonry layout w3c/csswg-drafts#10233 ; Alternative masonry path forward w3c/csswg-drafts#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:

• 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.

[fantasai]

Masonry Syntax Debate Overview

Introduction

The CSSWG has published a consensus FPWD of a masonry layout feature for CSS. See CSS Masonry Layout TAG Review Request for an overview of this specification and the discussions leading up to it. There is fundamental disagreement over the syntax model for this new layout mode, thus the FPWD includes two competing proposals.

The disagreements center around two key concerns: usability for authors, and extensibility into the future. The best way to understand these points would be to read these blog posts advocating for each:

• Chrome Blog: How should we define CSS masonry?
• WebKit Blog: Help us choose the final syntax for Masonry in CSS
• Ahmad Shadeed: Should masonry be part of grid?
• Rachel Andrew: Masonry and good defaults
• Keith J. Grant: Weighing in on CSS masonry [published before the merged FPWD]

We summarize the high-level disagreements below. For examples, please refer to the blog posts.

Usability for Authors

Learnability

• Chrome argues that a separate display type is easier to learn because a dedicated syntax and mental model can be tailored more closely to the characteristics of the layout, and because segregating layout into separate modules makes them easier to understand. They assert that Grid syntax would be interpreted differently or would otherwise be confusing when re-used for masonry layout.

• WebKit argues that an integrated display type is easier to learn, because it re-uses exactly an existing syntax and mental model, leaving minimal syntax and concepts to learn, even if there are slight differences in behavior in the two modes—allowing authors to easily switch between them mentally as well as in code.

Defaulting

• Chrome argues that using a separate display type allows for better default behavior, leaving fewer things to configure for common cases.
• WebKit argues that Chrome's proposed default values are not actually usable for most of the common cases; and therefore aren't better defaults. They assert that relying on automatic behavior at the container level just pushes down the need for configuration to the items, which is less understandable/performant/powerful.

Redundancy

• Chrome argues that re-using Grid's 2D properties means nearly every Grid feature has some syntax that is ignored or reinterpreted in Masonry's 1D layout; therefore re-using patterns rather than properties is better.
• WebKit argues that creating a separate display type with its own dedicated properties introduces a lot of slightly divergent duplicated syntax into CSS, where CSS usually re-uses properties across contexts wherever they can reasonably apply, ensuring a consistent and minimal interface to shared concepts.

Extensibility

Masonry layout and Grid layout have some key differences:

• Masonry layout imposes sizing consistency on all items in the same track in one dimension; regular grid layout imposes it in two dimensions.
• Masonry layout requires track sizing before auto-placement can occur (because auto-placement needs to know the sizes of already-placed items to determine where to place the next item), whereas regular grid layout requires placement before track sizing (because track sizes depend on what items were placed into them). We were able to introduce auto-sized tracks into masonry by sizing them with the assumption that all auto-placed item are placed into all tracks.

These differences mean that some layout operations are easier or more reasonable in masonry than in grid and vice versa.

• Chrome argues that by making masonry a separate display type it allows the feature set of masonry and grid layout to diverge, making it easier to introduce a feature in one without entangling it with the other. They cite the example of asking the UA to calculate how many auto-sized columns could fit in a masonry container, which would require heuristics in both but likely have more convoluted behavior in Grid.
• WebKit argues that by integrating masonry and grid, authors are guaranteed a consistent syntax and feature set, and this is worth the extra effort and complication to make a given feature work in both modes. They cite the example of mixing different track size types in a given masonry container, which Chrome had asserted was impossible to do performantly, but which the CSSWG has solved and specced in the FPWD.

Question

The CSSWG is seeking the TAG's input into this question, to help inform the debate.