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

Overall, we think masonry, grid, and wrapping-flexbox should be incorporated into a unified set of properties. Chrome's proposal splits apart property sets too eagerly, but even the WebKit proposal seems to miss a chance to develop more-general properties. 

Examining the arguments put forward from either side, we found some compelling and some less so:
1. It was argued that a separate set of properties is necessary for [sensible defaults](https://rachelandrew.co.uk/archives/2024/09/21/masonry-and-good-defaults/). However, there is precedent for using "smart" defaults that are different based on other property values. Perhaps the `masonry` shorthand can be used to set grid-integrated properties.
1. It was argued that the grid-integrated syntax makes it [easier to convert from grid syntax to grid-integrated masonry syntax](https://webkit.org/blog/16026/css-masonry-syntax/#simplicity-learnability), however we don't optimize for the transition period unless it's going to derail adoption.
1. It was argued that the grid-integrated syntax makes it easier to [switch between grid and masonry at a breakpoint](https://ishadeed.com/article/css-grid-masonry/#responsive-design) or [switch between row and column tracks](https://developer.chrome.com/blog/masonry-syntax#masonry_for_rows), however we don't expect this to be a common enough use case to be worth optimizing for. 
1. 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.
1. It was argued that the grid-independent syntax would also push future layout modes towards becoming separate property sets, which would be detrimental for the overall learnability of the language. We do think this has some basis, given the principle of [consistency](https://www.w3.org/TR/design-principles/#consistency), but there are also enough differences between pillar and masonry to justify different design decisions.
1. We appreciated the argument that [historically in graphic design grids were actually one-dimensional until relatively recently](https://webkit.org/blog/15269/help-us-invent-masonry-layouts-for-css-grid-level-3/#what-is-a-grid), although this doesn't prove that such grids fit into `display:grid`.
1. It was argued that because most masonry use cases are simpler than Grid, developers should be able to learn it without having to first learn Grid. This is an important goal. Can you instead achieve it by simplifying a subset of Grid that works for these types of simple cases? For example, multicol makes it easy to define several equal columns, optionally with constraints about their total number, min/max dimensions, or both. Can you share the track definitions between multicol and masonry? This need also arises fairly often with a 2-d grid: can the WG port this simplicity to Grid layout, and share the required properties across all three layout modes?

We also noticed some larger issues with the space of CSS layout modes:
* CSS currently has 3 layout modes all of which basically generate a 2d arrangement of children, with different rules for which dimensions line up and what order the available layout slots are filled: grid, multicol, and wrapping-flexbox. This is already causing a lot of author confusion, and Masonry attempts to add a 4th mode. As a general principle, having vastly different ways to accomplish slightly different things is a usability antipattern. 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.
* While sometimes inevitable, having properties specify things that get ignored is also an antipattern. It is particularly damaging to DX if from an author perspective it seems that these properties really ought to work together, but they don't. As specified, `grid-auto-flow` in the grid-integrated proposal falls in that category: we should not require authors to specify a flow axis that is then ignored.
* There's a wider space of layout patterns, including the [Flickr-style grid](https://github.com/user-attachments/assets/9586b6e9-94d3-4c57-a286-0445a491e587) and [layouts derived from magazines and newspapers](http://www.kevra.org/TheBestOfNext/ThirdPartyProducts/ThirdPartySoftware/PersonalProductivity/DocumentCreation/PagesByPages/files/page32_3.pdf), which CSS should eventually be able to represent. It's unfortunate to add a whole new layout mode without showing how it contributes toward the rest of the needed layouts. If we think of [multicol as being a grid with just one row](https://webkit.org/blog/15269/help-us-invent-masonry-layouts-for-css-grid-level-3/#what-is-a-grid), many of these patterns, including Masonry and ["pillar"](https://webkit.org/blog/16026/css-masonry-syntax/#a-possible-future-feature), seem to involve the ability to instruct the browser to stack the next child into one or more cells with some existing content. 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.

We recognize that it's important to make incremental progress and that it's impossible to break backward-compatibility with the existing properties. We hope there's a way to imitate the way `gap` was backported, but even if there's not, we think the new features' designs would benefit from a sense of what we would have done if we had a time machine.


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

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