[csswg-drafts] [css-grid-3][masonry] Longhand shorthand relationships of item-flow (#12804)

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

== [css-grid-3][masonry] Longhand shorthand relationships of item-flow ==
Following up on the adoption of `item-flow` in [#11480 Unifying grid-auto-flow and flex-flow](https://github.com/w3c/csswg-drafts/issues/11480) (see [this WebKit blog post](https://webkit.org/blog/16587/item-flow-part-1-a-new-unified-concept-for-layout/) for an overview of `item-flow`), one question we need to nail down is how, exactly, the various longhand properties involved relate to each other.

(There's still open questions on what the values mean, e.g. #12803, and perhaps some of these `item-*` longhands will get renamed, but these are independent questions from the shorthanding mechanics, which is the focus of this issue.)

* **Option 1: Aliasing** The `item-direction` property is an alias of `flex-direction`, while `item-wrap` is an alias of `flex-wrap`, and both are longhands of `grid-auto-flow`. Masonry, as well as grid and flexbox, therefore respond to both `flex-flow` and `grid-auto-flow`.
   * This essentially collapses `flex-flow` and `grid-auto-flow` as a single property for cascading purposes. It simplifies the model, but there were some concerns about whether it was Web-compatible, and also whether it's confusing for `flex-flow` to affect grids and vice versa.
   * `item-flow` would shorthand:
       * `item-direction` aka `flex-direction`:
       * `item-wrap` aka `flex-wrap`
       * `item-pack`
   * `grid-auto-flow` would alias `item-flow`, or maybe just be a shorthand of `item-direction` and `item-pack`

* **Option 2: Flex + Grid/Masonry Longhands** The `item-flow` property is a shorthand of `flex-flow` and `grid-auto-flow`, which remain independent. Masonry layout (being a variant of “grid”) responds to `grid-auto-flow`.
    * This maintains the independence of `flex-flow` and `grid-auto-flow`, and avoids introducing a third property set for masonry layout by re-using the `grid-*` longhands for it.
    * `item-flow` would shorthand:
         * `item-direction`, itself a shorthand of `flex-direction` and `grid-auto-direction`
         * `item-wrap`, itself a shorthand of `flex-wrap` and`grid-auto-wrap`
         * `item-pack`, which could shorthand new `flex-pack` and `grid-auto-pack` properties if we want, but doesn't have to
      * `grid-auto-flow` would shorthand `grid-auto-direction` and `item-pack` (or `grid-auto-pack`, if we split it out), and maybe `grid-auto-wrap` if we want

* **Option 3: Flex + Grid + Masonry Longhands** The `item-flow` property is a shorthand of `flex-flow`, `grid-auto-flow`, and a new `masonry-flow` property, which are all independent.
    * This prevents `grid-auto-flow` from affecting masonry layouts, at the cost of introducing a new parallel set of properties for controlling masonry layout.
     * `item-flow` would shorthand:
            * `item-direction`, itself a shorthand of `flex-direction`, `grid-auto-direction`, and `masonry-direction` or whatever
            * `item-wrap`, itself a shorthand of `flex-wrap`, `grid-auto-wrap`, and `masonry-wrap` or whatever
            * `item-pack`, which could shorthand new `flex-pack`, `grid-auto-pack`, and `masonry-pack` properties if we want, but doesn't have to
    * `grid-auto-flow` would shorthand `grid-auto-direction` and `item-pack` (or `grid-auto-pack`, if we split it out), and maybe `grid-auto-wrap` if we want

The new properties outlined here are of course subject to bikeshedding, and we can customize how the shorthand values map to the longhands so the value keywords can also be bikeshedded, but these are the three fundamental approaches we could take. Which one do we want?

My preference is for option 2, fwiw. Both because I want to lean into “masonry is a variant of grid layout”, and also because Yet Another set of flow-control properties seems like overkill. :)

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


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

Received on Monday, 15 September 2025 22:35:57 UTC