Re: [csswg-drafts] Alternate masonry path forward (#9041)

I mentioned a few friction points when trying to do Masonry in Grid, but didn't go into great detail. Here's a more complete list ^_^

Friction Points with Masonry-in-Grid
====================================

* `grid-template-areas` allows you to specify an N*M grid in Grid, but Masonry is a 1*N or N*1 grid. We can't reject too-large grids at parse time, so we'd have to specify that all but the first column/row are ignored when doing Masonry.

* `grid-template` is written substantially differently when defining an N*1 grid vs a 1*N grid. For example, to define three masonry tracks, you'd write either `grid-template: "foo bar baz" masonry / 10px 20px 1fr'` for columns, or `grid-template: "foo" 10px "bar" 20px "baz" 1fr / masonry;` for rows. (If you're manually specifying additional line names it gets even worse.) This seems pretty bad for authors to have to keep in mind! 

* Grid and Masonry allow different sorts of track sizing. `10px 20px 1fr` is a valid set of track sizes for both. `10px auto min-content` is a valid set of track sizes for Grid, but illegal for Masonry (per our argument in [9041](https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2075210820)). `repeat(auto-fit, 10px)` is also valid for Grid, but illegal for Masonry (per the spec, and for good reason). `repeat(auto-fill, auto)` is valid for Masonry (and very useful), but illegal for Grid.

    If they're both done in `grid-template-rows/columns`, we'd have to define what happens when you specify an "illegal" set of track sizes, and there's no good answer. It would be better if we could reject these at parse time, but that requires separate properties.

* `grid-auto-flow` doesn't do anything in Masonry, and `masonry-auto-flow` doesn't do anything in Grid. If we accept #10231 and merge the two together, then we have the same situation as the last bullet point - some values are valid in both, but others are valid in only one or the other, and we have to define what happens when you specify an "illegal" value.

* `grid` also integrates `grid-auto-flow` into its syntax, in a way that isn't meaningful for Masonry (the `auto-flow` keyword sets `grid-auto-flow: rows/columns`, which are meaningless in Masonry). We'd either have to make the `grid` syntax *even more* complex (and, again, still define what happens when you use the version that tries to set `grid-auto-flow`, and vice versa for using the Masonry version in a normal Grid), or just not let Masonry set its auto flow values in `grid` at all.

* Grid has four placement properties (and two props that merge a pair, and one prop that merges all four), setting the position of each edge of the grid item. Masonry can only set two of these; the other two are determined by the flow. This means we have to ignore three of the properties (two individuals and one pair) and part of a fourth (two of the values in `grid-area`, potentially) when a container is in Masonry mode.

* Grid can use all six of the `justify/align-*` properties, but Masonry uses only a subset (matching Flexbox, but hopefully without repeating the mistake Flexbox made of using main/cross axis rather than block/inline). So both `justify-content` and `align-content` work, but apply to different things (either aligning the tracks in the container, or the items in each track), but only *one* of `justify-self` and `align-self` work (and similarly for `justify-items`/`align-items`), depending on the track direction.

    (At least, I'm *supposing* that the `*-content` properties work like Flexbox, because that seems useful, rather than like Grid, treating the masonry axis as just a single track. The `*-self` properties definitely have to act like Flexbox, tho.)

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


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

Received on Wednesday, 24 April 2024 17:43:54 UTC