[csswg-drafts] [css-grid-3] Discussion overview for masonry syntax discussions (#11593)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-grid-3] Discussion overview for masonry syntax discussions ==
This is just a summarizing/guiding issue for the Grid 3/Masonry/Flexbox syntax, outlining the goals for the discussion and the rough priority @fantasai and I are assigning to them:

Roughly, the discussion covers four groupings of properties:

1. template longhands (track sizes, track names)
2. the other longhands (directions, slack, pack)
3. new `display` value, or `display:grid` + some toggle
4. shorthands

Here's the issues in more detail:

1. Should "masonry layout" use its own set of template definition properties (`masonry-template-tracks`, `masonry-template-areas`) or just reuse the `grid-*` ones (`grid-template-rows`/`grid-template-columns`, `grid-template-areas`, ignoring whichever of `-rows`/`-columns` is in the wrong axis). #11243
    * We have *almost* completely unified the set of allowed track-sizing behaviors between Grid and Masonry. Remaining divergence is "auto-repeating intrinsically-sized tracks", which are allowed in Masonry but don't seem to have an obvious useful/meaningful behavior in Grid.
    * `grid-template-areas` is well-suited for Grid with its syntax multiple strings, and assuming they'll be formatted across multiple lines to form "ASCII art" of the Grid areas. Masonry only ever has one dimension to name, tho.

2. Should we adopt the `item-*` set of properties unifying the *non-template* parts of Flexbox/Grid/Masonry definition? If so, which one? #11480
    * Original Apple proposal: <https://github.com/w3c/csswg-drafts/issues/11480#issue-2781495226>
    * Tab counter-proposal: <https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2591555448> (scroll to end of the comment)
    * Unified compromise proposal: <https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2620453349>
    * Something else?
    * If not, do we take the `masonry-*` properties from [Grid 3's "grid-independent" proposal](https://drafts.csswg.org/css-grid-3/#masonry-model-masonry-option)? (I'm [on record](https://github.com/w3c/csswg-drafts/issues/11243#issuecomment-2563983858) as being willing to Formally Object to the "grid-integrated" property set.)

3. Should "masonry layout" be its own `display` keyword, or just use `grid` + a control that toggles the grid into "masonry mode"? #11243
    * Item 1 is independent of this; we could still, in theory, re-use the `grid-template-*` properties with `display: masonry`.
    * In item 2, if we do a toggle:
        * If we do the `item-*` properties, it'll be part of `item-pack`, which also controls denseness and balancing. 
        * If we don't do `item-*` and instead have `masonry-*` properties, it'll be part of [`masonry-flow`](https://github.com/w3c/csswg-drafts/issues/11243#user-content-compromise-proposal), which also controls the masonry directions.
 
4. The `grid`/`grid-template` shorthands, as written, doesn't work for "masonry layout", and we can design a much better syntax. Should it just be another `grid` syntax branch? Or should it be its own `masonry` shorthand property? #11243
    * Wherever it lives, the syntax would be `<tracks> || <areas> || <direction> || <cross-direction>`, possibly + `|| slack <slack>`, setting all the template properties from item 1 and "other" properties from item 2.
    * If item 1 is resolved in favor of reusing `grid-template-*` properties, what do we do about the `grid-template` shorthand? 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11593 using your GitHub account


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

Received on Wednesday, 29 January 2025 02:42:36 UTC