Re: [w3ctag/design-reviews] CSS Masonry Layout (Issue #1003)

# Masonry Syntax Debate Overview #

## Introduction ##

The CSSWG has published a [consensus FPWD](https://www.w3.org/TR/css-grid-3/) of a masonry layout feature for CSS. See [CSS Masonry Layout TAG Review Request](https://github.com/w3ctag/design-reviews/issues/1003) 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](https://www.w3.org/TR/css-grid-3/#alternative-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?](https://developer.chrome.com/blog/masonry-syntax) 
- [WebKit Blog: Help us choose the final syntax for Masonry in CSS](https://webkit.org/blog/16026/css-masonry-syntax/) 
- [Ahmad Shadeed: Should masonry be part of grid?](https://ishadeed.com/article/css-grid-masonry/) 
- [Rachel Andrew: Masonry and good defaults](https://rachelandrew.co.uk/archives/2024/09/21/masonry-and-good-defaults/) 
- [Keith J. Grant: Weighing in on CSS masonry](https://keithjgrant.com/posts/2024/05/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](https://webkit.org/blog/16026/css-masonry-syntax/#simplicity-learnability), 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](https://developer.chrome.com/blog/masonry-syntax#points_to_consider_between_the_two_options_3), leaving fewer things to configure for common cases. 
- WebKit argues that Chrome's proposed default values are [not actually usable](https://webkit.org/blog/16026/css-masonry-syntax/#extending-masonry-with-repeatauto-fill-auto) 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](https://webkit.org/blog/16026/css-masonry-syntax/#:~:text=The%20proposed%20default), which is less understandable/performant/powerful.

### Redundancy ###

- Chrome argues that re-using Grid's 2D properties means [nearly every Grid feature has some syntax](https://developer.chrome.com/blog/masonry-syntax#points_to_consider_between_the_two_options_5) 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](https://webkit.org/blog/16026/css-masonry-syntax/#minimum-redundancy-repurposing-use-what-is-there) 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.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1003#issuecomment-2456252511
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1003/2456252511@github.com>