[css-flexbox][css-grid] Unifying grid-auto-flow and flex-flow

[fantasai]

The TAG response to the masonry syntax issue asked us to look into unifying controls for our layout modes, calling out grid-auto-flow and flex-flow (flex-direction + flex-wrap) in particular. Apple looked into this, and we have the following syntax proposal:

Introduce item-flow aliased to both flex-flow and grid-auto-flow and defined as a shorthand for the following properties:

• item-direction (also aliased as flex-direction)

  • row | column | row-reverse | column-reverse

• item-wrap (also aliased as flex-wrap)

  • auto | wrap | wrap-reverse | nowrap
  • auto computes to either wrap (for Grid) or nowrap (for Flexbox)
  • nowrap in Grid would mean autoplacement adds implicit tracks instead of wrapping to the next row

• item-pack

  • normal | dense
  • Defining dense packing for Flexbox would mean that instead of breaking lines as soon as an item can’t fit, we try to cram in one more, triggering flex-shrink behavior instead of flex-grow on that line. See [css-flexbox-2] Add flex-wrap: dense #3071.
  • This syntax allows the potential to expand packing controls, e.g. item-pack: normal | dense || [ collapse | balance ] could allow:
    • collapse triggering a masonry-style layout for Grid (see [css-grid-3][masonry] Masonry Syntax Debate #11243).
    • balance opting into balanced line-wrapping for Flexbox ([css-flexbox-2] Add flex-wrap: balance; #3070).

• item-slack

  • <length-percentage>
  • This is the masonry-slack property. See [css-grid] Decide on a name for masonry-slack #10884.
  • For Flexbox, slack could say at what point you switch from loose packing to cramming:
    • In normal mode, 10px slack would mean “if there’s only 10px overflow on this line when adding the next item, cram it in anyway, as squeezing in an extra 10px is no big deal”.
    • In dense mode, 10px slack would mean “if there’s only 10px empty space left on this line, don’t try to cram in the next item, that’s too much cramming”.

Caveats: This would make flex-flow and grid-auto-flow cascade as a single property, which is a change in behavior and therefore could have some Web-compat impact.

Variations: This is our initial sketch, but there are some variations we’ve considered:

• We’re unsure if item-slack should be a longhand of item-flow or not: it's often nice to put it in the item-flow shorthand, but it might also make sense for it to cascade independently.
• We’re open to ideas about the item- prefix. Ideas we’ve come up with so far include item-, box-, items-, and placement-. (We’re drawing the “item” terminology from the specs and from the align-items property.)

Thoughts?

[jyasskin]

I wanted to comment on one piece of this. The rest looks like a great direction to explore, but I'm not enough of a CSS expert to opine that it's definitely the way to go.

Giving a *-direction property values of row and column is ambiguous between "the items are laid out in the row direction" and "the items form visual rows". With flex, these were equivalent; with grid, you always get both rows and columns; but with masonry, they're opposites. I was also surprised to learn that in a vertical writing system (e.g. writing-mode: vertical-rl), "row" means "top to bottom", although it's possible that this is natural to native speakers.

Fundamentally, these say whether to stack items in the block or inline direction. So maybe item-direction should take values of inline, inline-reverse, block, and block-reverse?

[JoshTumath]

It's great that we're starting to think about solutions to the TAG recommendation for unified layout properties. I think this is a good proposal. And I agree item-* is the best prefix.

Do you see this as part of a family of other item-* properties? Is there any other low hanging fruit of layout properties that could be unified?

For example, I wonder if maybe the syntax for columns and grid-template-columns could be unified as well? columns: 10rem does something a bit similar to grid-template-columns: repeat(auto-fill, 10rem) .

However, I'm thinking about how there are still lots of essential properties needed for each layout system that are unique to each layout system. For example, to create a flex or grid layout, I'm still most likely going to use flex or grid-template-columns.

If I mixed them together in the same layout, I'd probably write something like this:

.my-layout {
  display: flex;
  item-flow: row-reverse wrap;

  > * {
    flex: 1;
  }

  @media (width > 20rem) {
    display: grid;
    grid-template-columns: repeat(auto-fill, 8rem);
  }
}

In the above example, using item-flow has saved me from needing to specify flex-wrap: wrap, flex-direction: row-reverse and grid-auto-flow: row-reverse. But I still won't get the layout I want without flex and grid-template-columns.

[tabatkins]

(tldr: complaints up top, counter-proposal near the bottom)

I don't think this proposal works. If we were just talking about Flexbox and Grid, this seems pretty reasonable, to the point that I'd likely have supported it if was suggested a few years ago. But in trying to wedge Masonry into the same framework of property and value names, it makes some pretty serious mistakes.

In both Flexbox and Grid, the row/column keyword means "the meaningful layout grouping" (flex lines, or the meaningful direction of grid tracks) matches the keyword: row indicates your flex lines are laid out as rows, or that your grid items are laid out in rows, moving to the next row when one is full and possibly creating new rows if needed. column indicates the opposite. row-reverse and column-reverse both indicate that this layout group is filled in the reverse order, from end to start, rather than start to end as normal.

Also, the wrap/etc keywords in both Flexbox and Grid indicate the direction you wrap to when the row/column (as chosen above) is full; wrap or wrap-reverse tells you where to place the next flex line, or which next grid track to search and where to create new implicit grid tracks when needed.

So far, so good: these two layout modes (Flexbox, and Grid auto-layout) have very similar concepts, used in very similar ways, and the same sorts of terms apply meaningfully across both. There's some tension - dense doesn't have a good meaning in Flexbox (note that the cited issue #3071 is talking about a different behavior than what's proposed here, and neither behavior is really analogous to what Grid is doing †¹), and nowrap doesn't have a good meaning in Grid (I don't understand the behavior described here, but the "no wrap" behavior is already doable by giving the auto-placed item an explicit row or column placement), but either some meaning can be defined for them, or we can define them as error cases and give them a default behavior. Unfortunate, but with some precedent. This is probably a worthwhile cost to pay for the benefit of reusing a single set of properties and values.

These arguments don't apply to Masonry.

@jyasskin brings up the first issue: this proposal defines that row indicates a Masonry whose meaningful layout unit (masonry tracks) is columns. This means the standard Pinterest-style layout would be indicated with item-flow: row collapse, but then pay attention to grid-template-columns, use grid-column for explicit position, etc. This is confusing!

Second, the row-reverse/column-reverse keywords also don't mean the same thing. In Flexbox and Grid, row means each new item will be placed end-ward of the previous item in the same row, while row-reverse means each new item will be startward. But in this proposal for Masonry row-reverse just indicates how to break ties when deciding which column to flow the item into. When placing the first few items in the Masonry this does resemble the usage of row-reverse in the other two, but as soon as the column edges get ragged due to differing item heights, it diverges significantly, only occasionally affecting an item's placement. Most of the time, whether the next item is placed startward or endward of the previous has nothing to do with the keyword, being instead determined by which column is currently shortest. (In the degenerate case where all items are the same size the similarity does persist the whole time, but in that case using Masonry doesn't actually do anything; you could have just used a Grid with identical effect.)

Third, the entire concept of wrapping doesn't apply to Masonry. This proposal defines it as dictating in which direction Masonry fills its tracks, but this exact concept is controlled by item-direction for the other two layout modes! Masonry does not "fill" a layout unit in any meaningful way, and then create new layout units to put subsequent items in, needing a control for where to play the new ones, like Flex and Grid do with their wrap keywords.

Fourth, the additional values still don't have great meanings in Masonry:

• nowrap doesn't appear to have any possible useful behavior. (I guess it would just put a single item in each track, and generates as many tracks as there are items? That doesn't seem worthwhile to define.).
• dense has a decently analogous behavior to Grid's definition, but it happens much more rarely, only affecting placement when you're mixing items of varying spans, and only working well when all your tracks are the same size. (In Grid it helps fill in the ends of rows when an item was too wide to fit in the leftover columns and got moved to the next row instead. In Masonry, the placement rules already handle that situation by default. Masonry only gains "holes" to fill if a spanning item covers multiple columns of varying heights. And for perf reasons, it's only allowed to search for holes in the same track as where it would normally be placed, or other tracks with the exact same size.)
• Masonry adds collapse to indicate the grid is doing masonry rather than normal grid layout, but that doesn't have any meaningful definition for Flexbox.
• balance has been discussed for Flexbox, but that doesn't have any meaningful definition for Grid or Masonry.

Fifth, while I think applying the 'slack' concept to Flexbox is pretty interesting and worth pursuing †², afaict there's no meaningful definition for Grid.

In conclusion, I think this proposal makes some unacceptable design decisions, which are forced on it due to trying to fit Masonry's layout concepts into the "direction + wrap" concept pair that Flexbox and auto-Grid use. I would oppose this. Instead, Masonry needs its own set of properties to handle the "direction + tie-breaking" concept pair that it actually uses, as I proposed in #11243 (comment).

---

If we did want to define a single collective set of properties, I think it's possible! A good design just has to recognize that some concepts don't apply to some layout modes, rather than trying to cram all of them into the same set of concepts, like how different layout modes use different subsets of the place-* properties. We'd instead go with:

• item-direction: row | column | row-reverse | column-reverse: works for all three layout modes, giving the direction of the primary linear layout unit, and which direction to fill that unit in. (So, the standard Pinterest layout is indeed column.)
• item-wrap: no-wrap | [ wrap | wrap-reverse ] || balance?: only works in Flexbox and Grid. In Grid, nowrap is ignored and treated as wrap, and balance is ignored.
• item-ties: tie-start | tie-end: only works in Masonry. (Maybe it could apply to a dense Grid or a "dense Flexbox" as I defined it below in †¹; tie-start gives today's dense behavior that always places as early as possible, while tie-end instead places it in the last position preceding the cursor that it fits in, if possible; otherwise in its normal position. That way, items tend to stay close to source order while still filling in gaps.)
• item-pack: normal | dense: works in Grid and Masonry. (Maybe works in Flexbox, as one of the explored possibilities.)
• item-slack: <length> | infinite: works in Masonry, and Flexbox as described in the first post of this thread.

If we use Grid-masonry, we'll still need a separate way to indicate that a given Grid is using Masonry instead of Grid layout. If using display:masonry, that's already covered, and leaves us with only masonry-template-tracks, masonry-template-areas, and masonry-track as masonry-specific properties, plus the masonry shorthand that sets some of the item-* props as well.

---

[edited to move some comments to #3071]

[kbabbitt]

An idea that's been floating in my head (to point 2 of my comment in #11243) is to have a property that both selects between, and parameterizes, flexbox/grid/masonry/etc. Something like:

item-auto-placement:
  	  no-wrap    /* non-wrapping flexbox */
	| flex-wrap [reverse]
	| grid-wrap [reverse]
	| shortest [favor-start | favor-end]    /* masonry, with favor-* describing how to break ties */

The grammar's a bit more verbose, but the branching leaves room to avoid the problems of specifying combinations that don't make sense.

That particular example also leads to item-flow: shortest column in the shorthand for a classic masonry layout, which I find really expressive.

[tabatkins]

Moved some comments about Flexbox's dense and *-slack behavior to #3071, at @fantasai's request.

My alternate proposal for those Flexbox behaviors is presented in a small final comment.

[tabatkins]

@fantasai and I did some brainstorming yesterday to reconcile our ideas: keeping the "track-centric" naming system from my counter-proposal that I find important, while reducing the amount of divergence among the layout modes in it, which fantasai finds important. I think this proposal we've come up with is acceptable, and sufficiently extensible for future layout modes.

item-track: auto | row | column | row-reverse | column-reverse
item-cross: [ [ nowrap | wrap ] || [ normal | reverse ] ] | wrap-reverse
    /* wrap-reverse is a combination of wrap and reverse, for convenience */
item-pack: normal | dense || [ collapse | balance ]
item-slack: normal | <length-percentage> | infinite
item-flow: <'item-track'> || <'item-cross'> || <'item-pack'> || <'item-slack'>

The core difference between this proposal and Apple's proposal is how they map onto the two axes: in this proposal, row/column/etc describes the track axis--i.e. the resulting layout that you see--whereas in Apple's proposal it describes the primary placement direction. (That is, "a masonry layout, arranged into columns" uses the column keyword, same as "a flexbox layout, arranged into columns" does.) I believe this is greatly more intuitive, even though it means that flex/grid and masonry layouts that flow in a given direction can't share their item-flow values.

It also generalizes the property name and values for the "cross axis flow" property, called item-cross here: rather than being intrinsically wrap-specific, it just uses normal/reverse and leaves the exact interpretation up to the layout mode. In Flexbox/Grid it's the direction you add new tracks in; in Masonry it's the direction you break ties in when there are multiple tracks with the same height. wrap/nowrap only mean something in Flexbox; Grid always wraps, and Masonry doesn't have a wrapping concept in that axis, so they ignore those keywords if specified. Future layout modes can define what their cross-axis direction means, and if wrapping is optional, can pay attention to the wrap keywords.

It otherwise matches @fantasai's earlier proposal wrt the other properties item-pack and item-slack. (I'll want to quibble over the definitions of the Flexbox dense & slack behavior, but that's a different issue.)

Some examples:

// create a column masonry:
display: grid;
grid-template-columns: ...;
item-flow: collapse;  // because grid-template-rows: none, resolve "item-track:auto" to "column"

// create an auto-flowing grid growing downward
display: grid;
grid-template: ...
item-flow: row; // not strictly necessary; 'item-track' defaults to "row" in non-Masonry Grid.

// create a row flexbox
display: flex;
// in flexbox, "item-track:auto" defaults to "row"

[css-meeting-bot]

The CSS Working Group just discussed [css-flexbox][css-grid] Unifying grid-auto-flow and flex-flow, and agreed to the following:

• RESOLVED: Continue to work on the item-* props as a set of switches for all items-in-container layout modes
• RESOLVED: Put it in grid-3 for now, with intention to move

The full IRC log of that discussion

<bramus> fantasai: one of the key feeedback points from tag was to see better unificiation between grid and flexbox and grid auto flow and flex flow
<bramus> … also grid auto flow aspect of the grid integrated proposal was pointed out by google to be awkard
<bramus> … want to unify in a reasonable way
<bramus> … some ideas in the issues
<bramus> … tab had some variations on that
<bramus> … jen created a presentation to walk us through all of it
<bramus> florian: are you presenting a synthesis or a propsal?
<bramus> jensimons: both
<bramus> … one of the areas that is difffern betwwn both proposal is grid auto flow vs masonry direction and such
<bramus> … tag reviewed that
<bramus> … need more general properties
<bramus> … flexbox: have direction, wrap and flow
<ntim> jensimmons: let's go down this rabbit role
<bramus> … grid; no directoin or wrap, but auto flow
<bramus> … unified: maybe some item-* props?
<bramus> … item-direction, item-wrap, item-pack, item-slack, item-flow, …
<bramus> … leading to new ideas for grid and flex
<bramus> … intersting things
<bramus> … new homes for long standing feature requests
<bramus> … things click together suddenly
<bramus> … grid could gain nowrap
<bramus> … to not define expcliit tracks and have all implicit tracks and have grid autocreate rows or cols
<bramus> … flexbox gains dense packing
<bramus> … it can backfill if items fit on a previous line that was already filled
<bramus> … flexbox could get balance
<bramus> … thanks to item-pack
<bramus> … we could have something to balance the rows out a bit more
<bramus> … few ideas
<astearns> q?
<bramus> … and there is item-pack: collapse
<bramus> … (names TBD BTW)
<bramus> … and item-flow as a shorthand
<bramus> … with collapse we get into masonry
<bramus> … had the "just use grid" idea
<bramus> … or a new display value – masonry
<bramus> … with item-pack we can unify that: item-pack: row collapse
<lea> q?
<lea> q+
<bramus> … high level questions
<TabAtkins> q+
<bramus> … 1. do we want to pursue item flow and longhands, unifying grid-auto-flow?
<bramus> … 2. do we want to use item-pack as the trigger for masonry style?
<bramus> 3. (bikeshedding)
<bramus> … 4. decide what row and column mean for item-direction
<bramus> … does it mean flow of items or shape of layout?
<bramus> … ** shows example with named area columsns **
<bramus> … in grid it flows back in rows with grid-auto=flow: row;
<bramus> … with just use grid consistency is contained, but masonry-flow; coljunn describes the columns
<bramus> … (example with named area rows)
<bramus> … in the unified world … been discussing in context of masonry alone, but should be consistent for grid and flexbox too
<bramus> … flex-flow: row wrap vs item-flow: row wrap;
<bramus> … with grid its a bit different
<bramus> … grid-auto-flow: row wrap;
<bramus> … item-flow: row wrap; is a bit different
<bramus> … (missed)
<lea> `flow-direction` perhaps?
<bramus> … adding one more paper cut adding to the syntax
<bramus> … shape of the layout would be the
<bramus> … in masonry style layout it becomes clearer
<bramus> … is it item-flow: row collapse wrap;
<bramus> … but I know there are people who dont like that
<bramus> … so yeah, we have 4 questions
<bramus> … question about shape vs flow is ??? might help to write out examples
<iank_> q+
<oriol> q+
<astearns> ack lea
<bramus> lea: was one of th epeople on tag. this is great.
<bramus> … really like this
<bramus> … obvs things to bikeshed, but right direction
<bramus> … getting towards a simpler thing eventually
<bramus> … and seems more powerful than what was previously proposed
<ntim> q+
<bramus> … like how it leaves the template open – both rows and cols
<bramus> … can still have masonry layou tand efine a specific row height and that still has an effect
<bramus> … quite like that as well
<bramus> … did suggest flow-direction instead of item-flow
<bramus> … a bit weir dbut no strong opinion
<bramus> … details can always be fleshed out
<astearns> ack TabAtkins
<bramus> … this is fantastic
<bramus> TabAtkins: overall pretty happy with to move this functionality to item-* props
<bramus> … am very happy with it
<bramus> … one bit of objection which is item-pack property (after talking with ian)
<bramus> … conflict between new behaviors needing to be defined for all things
<bramus> … comes up here too
<astearns> qq+
<bramus> … side bits of behavior needed
<bramus> … item pack is more of a grab back of functinality
<bramus> … triggers betwen normal and dens in grid
<bramus> … swtich between grid and masonry
<ntim> s/grab back/grabbag
<bramus> ¬… and possibly turn flex in a ???
<bramus> … new piece of fn that needs to predefine things for deverything
<bramus> … inclined to not do item-pack
<bramus> … but accept all the rest
<florian> q+
<bramus> astearns: i like the discipline of needing to consider all layouts that a new thing might need to adapt to
<astearns> ack astearns
<Zakim> astearns, you wanted to react to TabAtkins
<bramus> … would still need to have an escape hatch where we could define values like flex-balance for item-pack that only work on flex until we figure out how to make balance work with the rest
<bramus> TabAtkins: definitily possible
<bramus> iank_: what tab said
<bramus> … item pack is problematic for reasons that tab outlined
<fantasai> +1 astearns
<bramus> … historically done a poor job as implementers
<bramus> … impltd these in block step (>)
<bramus> … this hurts devs bc they cant feature detect
<bramus> … stuff in alignment that was hard to ship
<astearns> s/would still need to have/would still have/
<bramus> … and things like align-content: baseline
<bramus> … historically done a bad job at these sort of complex things
<bramus> … would be a bit happy with this (i am working on balance in flex). for grid its very complex
<bramus> … dont want to see that we cant ship balancing for flexbox bc we have to figure out what it does for grid
<bramus> … layout specific keywords
<astearns> ack iank_
<bramus> … implementation cost would be huge otherwise
<astearns> ack oriol
<bramus> oriol: concern this seems to add fn that may add duplication or sth that may not really make sense in some layouts
<bramus> … in grid you can assign expl positions for the items and nowrap does not make sense in that case
<jensimmons_phone> q?
<bramus> … idea about nowrap adding new cols
<bramus> … with grid auto flow col you get that
<jensimmons_phone> q+
<bramus> … is duplication
<bramus> … will create more confusion
<bramus> … for authors
<bramus> … thing of item-pack to refer to the direction or shape of layout
<iank_> q+
<bramus> … not using shape of layout would be confusing
<bramus> … in grid auto flow that would a conflict was presented
<bramus> … though inc ase of non masonry grid you get both rows and cols
<bramus> … it does not apply well
<bramus> … some of these may make sense, but would prefer to add them explcity for each layout
<bramus> … not fond of defining everything in gereral because of duplication or conflicts
<astearns> ack ntim
<bramus> ntim: comment on item-flow
<bramus> … flow representes how things are ordered, not shape
<bramus> … so using shape would be confusing
<astearns> ack fantasai
<Zakim> fantasai, you wanted to comment on flow-direction, maybe
<bramus> fantasai: agree 100% with what alan said
<bramus> … i thinkk that idea of prefixing as we introduce new fn is an nice compromise to getting full allignment across layouts
<bramus> … idea iof flow-direction
<bramus> … (missed)
<bramus> … use flow in 2 places now
<bramus> … 1 is in various flow-???. its a suffix
<bramus> … 2 is why this could not be a shorthand
<bramus> …æ still have display: flow
<bramus> … these props dont apply to that type of layout
<bramus> … have 2 types of layout in CSS: flow layout <details missed> and a different kind of layout where you go down from parent to childrena and child is a chunk and gets manipulated as an item
<bramus> … flex and grid are in one type of those
<astearns> flow layout versus item layout
<bramus> … dont want to get too deep into wraping this set of props with the flow word
<bramus> … other that we use it as a shorthand to ???
<bramus> ; thought about prefixed
<bramus> … item was 1
<astearns> (or item-in-a-container layout)
<bramus> … thought about placement too
<bramus> … went with item bc we use item in align-items
<bramus> ; already have the concept of items
<bramus> … and syntax for it
<bramus> … open to naming of course
<astearns> ack florian
<bramus> florian: i like this
<bramus> … and generally agree with alans comment
<bramus> … re: ian
<bramus> … not everyting is the same
<bramus> … a bunhc o fthings need to work across layout modes
<bramus> … like margin and gap and rows and align and ;
<bramus> … if we dont do that its bad
<bramus> … not sure its all of it though
<bramus> … possibly around item-pack
<bramus> … squeeze mode of flex
<bramus> ; 2 proposals for what dense might mean for flex
<bramus> … looks like grid, but there are some flexbox-specific traits to it
<bramus> … when some of them are not diff appls of the same thing but related but diff concepts, then we get into the “you have to define all across all 3 modes”
<astearns> ack fantasai
<Zakim> fantasai, you wanted to react to florian
<bramus> … theres at least a part tha tmakes sense across all layou tmodes but not all
<bramus> fantasai: there was a proposal for dens epacking in flexbox (unrelated to this proposal)
<bramus> … idea was to instead of fill line and wrap when it overflows, cram in last items and shrink it
<bramus> … first edition of that tagged that behavior to the dense keyword
<bramus> florian: that is the dens keyword?
<bramus> fantasai: no
<bramus> … the thing on the slide is different
<bramus> TabAtkins: oh, the slide is not up to date I see
<bramus> fantasai: so, dense packing for flex should be same concept as grid to fill in the gaps
<bramus> … slack is cram things in
<astearns> q+
<bramus> … for masonry its which col is the shortest
<astearns> ack fantasai
<Zakim> fantasai, you wanted to clarify this
<dholbert> +1 to florian's concern, particularly for cases where the relative utility and/or implementation-complexity of the the same keyword is substantially different between different layout modes (which risks implementors shipping the feature for one layout mode but not others, as Ian noted)
<bramus> …for flex its close enough to fitting and ifts close to 10px cram it in
<bramus> … fudge distance
<bramus> … say how much you want to cram in
<bramus> florian: and in grid?
<bramus> TabAtkins: nothing, not possible there
<bramus> fantasai: the only keywords tied to 1 layout in this set are collapse for grid and balance only for flexbox
<bramus> florian: makes sense
<bramus> … lets try not to overfit this
<bramus> … would be a mistake
<bramus> … forcing that would be bad
<bramus> TabAtkins: strong agree
<bramus> … that is why i am happy with the current form
<astearns> ack jeroen
<astearns> ack jensimmons_phone
<bramus> jensimmons: an early reaction was to not do pack
<bramus> … and folks were sort of bummed out about doing balance
<bramus> … think that creating balance – doing balance keyword at all … can be a later version
<bramus> … exciting to present the propposed thing where it paints the future
<bramus> … dense already have for grid, can figure out what it does for flex
<bramus> … dont have to ship right away
<bramus> … ipml detail
<florian> s/lets try not to overfit this/lets try not to overfit this, by forcing the creation of different-but-analogus options in other layout modes just because we now have a keyword that could trigger them
<bramus> … collapse though is the toggle for masonry
<fantasai> s/detail; let's think about what's good for the Web/
<bramus> … skipping all of item pack
<bramus> TabAtkins: there’d be a diff switch
<florian> s/would be a mistake/would be a mistake, because it would force synchronous shipping of essentially unrelated (even if similar) functionality
<bramus> jensimmons: exciting things to add pack and slack here
<bramus> … (missed)
<astearns> ack iank_
<bramus> iank_: one thing, handling balance
<ntim> jensimmons: what's exciting is the unified way to control the flow for authors
<bramus> … imminently would be good
<bramus> … in the next month or so i’ll prolly do some research
<bramus> … would like to solve soon
<TabAtkins> concretely, instead of item-pack, we could keep the existing `grid-auto-flow`, add `flex-pack: normal | dense`, add balance to `flex-pack`, and trigger masonry layout via `display: masonry` or another new property.
<bramus> jensimmons: it is cool
<bramus> iank_: yep!
<astearns> ack astearns
<bramus> astearns: response to florian but i think jen covered it already
<bramus> … this new stuff is not the new item in containers property set to rule them all
<fantasai> I think having the unified properties is cooler than introducing more one-offs
<bramus> … this is a support mechanism that we use when appropriate to put them together where it makes sense
<bramus> … still lmost likely to have values with layout prefixes
<bramus> … spefific to those modes
<bramus> … that dont make sense into this other thing
<fantasai> s/values/values and properties/
<bramus> … but q is how do the existing or future layout props with these new item things?
<bramus> fantasai: this propopsal is meant to be replacing the existing grid-auto-flow and flex-flow props
<bramus> … is it an alias or how does it interact? thinking about making it a shorthand
<bramus> … 3 diff directions
<bramus> … alias, keyword magic, or shorthand
<bramus> … its not gonna rule all of layout controls, its this set of stuff to represent common concepts for all layout modes
<bramus> … gives them a unified home to live in
<bramus> … like flex property is not gonna be ported to grid or stuff
<bramus> jensimmons: think of things like alignment
<bramus> … does 1 thing
<bramus> … do they wrap or pack
<bramus> … its not about the layout at all, its about the item behavior
<astearns> s/likely to have values/likely to have values and properties/
<bramus> … when brendan and I came up with this, these props could alias other props
<TabAtkins> q+
<bramus> … but proplem with that we could end up with strange behavior where a strey prop starts to have effect
<bramus> … would expect that the flex props dont escape that
<bramus> … (missed)
<bramus> … authors can still grab to the flex and grid props
<astearns> +1 to not aliasing, that seems too constraining (and dangerous)
<bramus> … if we wnated in the future to define balance only for flex, then we can stick to that
<astearns> ack TabAtkins
<bramus> TabAtkins: this set of fn (with or without item pack) is sufficiently generic or useful dfns that they will be usable for prolly all future layout modes
<bramus> … knowing where it flows is always gonna be present
<bramus> … this is a good design set of pieces that will work for future layout modes
<bramus> … there should be direct analoging behavior between everything
<bramus> iank_: item-pack is arguably the one that violates that the most
<bramus> … bheaviors are diff between the modes
<bramus> … thats the one
<bramus> fantasai: dont think this is the case
<bramus> … normal is normal
<bramus> … dense is analogus between flex and grid
<bramus> TabAtkins: but not masonry
<bramus> fantasai: but it also has dense
<TabAtkins> nm, masonry does have dense
<bramus> … collapse gonna set out next separtely
<dholbert> q+
<bramus> … leftover one is balance. masonry is inhernetly that
<bramus> … only 1 keyword
<bramus> iank_: there is also nowrap
<bramus> fantasai: there is a dfn for nowrap that makes sens for grid
<bramus> … (grid)
<TabAtkins> The set of property names/values from mine and fantasai's compromise, btw, are:
<TabAtkins> item-track: auto | row | column | row-reverse | column-reverse
<TabAtkins> item-cross: [ [ nowrap | wrap ] || [ normal | reverse ] ] | wrap-reverse
<TabAtkins> /* wrap-reverse is a combination of wrap and reverse, for convenience */
<TabAtkins> item-pack: normal | dense || [ collapse | balance ]
<TabAtkins> item-slack: normal | <length-percentage> | infinite
<TabAtkins> item-flow: <'item-track'> || <'item-cross'> || <'item-pack'> || <'item-slack'>
<bramus> … this lets you set it at a higher level on the container
<bramus> … and that gets you similar to a nonwrapped flex box where you cerate tracks and apply certain track sizing mutations on it
<bramus> … and its a very obvs straigth way to get that
<bramus> … in grid you use grid-row: 1
<bramus> … but now you can add it at a higher level
<bramus> … not critical to add now, but i think it makes sens
<astearns> ack dholbert
<bramus> … not higghly reqd feature but straightforward to describe and implement
<bramus> dholbert: share ian’s concerns
<bramus> … in particular feels dense is well defined for grid but not sure i like the behavior for flex
<bramus> … seems like that behavior would be unpredicatable as space grows or shrinks
<bramus> … with rows and small items snapping down to a later row
<bramus> … you would get sth that looks like masonry with a lot of tiny items attached to the end of each line
<iank_> i also wonder a subset of requests for `flex-wrap: dense` was people really wanting `flex-wrap: balance`
<bramus> … would do the job to fill a line densely, bu tskeptiacal if that is what authors want
<bramus> … feels like dense is agrid thing that gets backfilled into flexbox
<bramus> … on the flip side it seems like balance might needed to be backfilled to grid
<bramus> … worried about being forced to implement both in order to ship 1
<TabAtkins> note: we can defer the item-pack property for discussion in another issue or later meeting. it would just remove one possible "masonry" switch
<bramus> astearns: see tab’s note in irc: can defer dense
<bramus> TabAtkins: if we end up to not put dense into item-pack and only had collapse then it would not be a good name for it
<bramus> … but does not prevent us from doing a diff switch from now and later have item pack take on those duties
<bramus> astearns: aside from some details, i hear general enthusiasm?
<bramus> … shall we resolve to continue to work on this general item-* prefix proposal?
<bramus> … seeing thumbs up
<bramus> … concerns?
<bramus> TabAtkins: and ideally resolve in upcoming telecons soon
<TabAtkins> items-in-container layout modes
<bramus> astearns: not hearing stuff, prop resolution is to continue to work on the item-* props as a set of switches for all items-in-container layout modes
<florian> +1
<kbabbitt> 👍
<bramus> RESOLVED: Continue to work on the item-* props as a set of switches for all items-in-container layout modes
<bramus> fantasai: curerntly to be shoved in the grid-3 spec
<bramus> jensimmons: could end up using its own
<bramus> florian: can move eventually
<ntim> ntim: could use css-display
<bramus> PROPOSED RESOLUTION: Put it in grid-3 for now, with intention to move
<bramus> RESOLVED: Put it in grid-3 for now, with intention to move
<ntim> <3

[tabatkins]

@fantasai and I wrote up the item-flow idea into the Grid 3 spec (as an appendix) and republished a Working Draft. We marked all the open questions as issues in the draft.

We encourage people to take a look and continue the conversation here.

[ydaniv]

@tabatkins one typo: in item-track/item-direction the text for row and column was copy-pasted without changes.

sent PR