[css-grid-3][masonry] Longhand shorthand relationships of item-flow

[fantasai]

Following up on the adoption of item-flow in #11480 Unifying grid-auto-flow and flex-flow (see this WebKit blog post 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 andgrid-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. :)

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-3][masonry] Longhand shorthand relationships of item-flow, and agreed to the following:

• RESOLVED: Go with option 2

The full IRC log of that discussion

<kbabbitt> astearns: on this one, you said option 2
<kbabbitt> ... I thought I heard you say that option 2 did not have problem of flex-flow affecting masonry layout but it seems like it does to me
<kbabbitt> fantasai: it doesn't
<kbabbitt> TabAtkins: in option 2, individual layout modes have their respective properties
<kbabbitt> ... we just have a shorthand for them
<kbabbitt> ... you could read auto-flow but it doesn't transfer over
<kbabbitt> astearns: it's a little weird to have a shorthand when you could set grid and flex separately and have only one apply
<kbabbitt> fantasai: not sure I follow, item-flow sets both
<kbabbitt> florian: but you can't use the shorthand to set grid to one and flex to the other
<kbabbitt> TabAtkins: astearns wasn't asking for that, said it would be confusing if you could
<kbabbitt> fantasai: could design that but would need to be pretty explicit about it
<kbabbitt> ... [writes syntax for it on the slide]
<kbabbitt> ... could consider what happens if you set both independently, not expecting use of this double syntax
<kbabbitt> florian: not convinced we're starting from scratch introducing things
<kbabbitt> ... but we do have them, flex properties don't affect grid, just aliasing everything seems undesirable to impossible
<kbabbitt> ... option 2 has weirdness but others seem worse
<TabAtkins> I like option 2 as long as we can it through ^_^
<kbabbitt> astearns: anyone want to argue against option 2 or suggest alternatives?
<kbabbitt> ... shall we resolve on option 2?
<kbabbitt> astearns: given that preference from both fantasai and TabAtkins and not hearing any opposition, proposed resolution is to go with option 2
<kbabbitt> ... objections?
<kbabbitt> RESOLVED: Go with option 2
<kbabbitt> fantasai: there's only one detail here, if we want item-flow to be able to set different values ...
<kbabbitt> astearns: let's make a note and only get to it if we have to
<kbabbitt> fantasai: i can't imagine anyone wanting to set it, but if an author sets flex-flow one way and grid-auto-flow the other way, what do we return for the shorthand?
<kbabbitt> ... not a representative value
<kbabbitt> TabAtkins: seems fine to me
<kbabbitt> astearns: an alternative would be to preference one or other
<TabAtkins> play stupid games, win stupid prizes
<kbabbitt> miriam: is that not normal or auto?
<kbabbitt> florian: no because if you set it to normal, that would do the weird thing where they disagree
<TabAtkins> item-flow:abnormal