- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 22 Oct 2025 16:43:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] item-flow row vs. column in masonry layouts`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> fantasai: [presents slides]<br> <kbabbitt> fantasai: talking about masonry and item-flow<br> <kbabbitt> ... we ran polls to get impressions at various moments of time<br> <kbabbitt> ... sections will end up interacting, once we're done with review I'll open for questions<br> <kbabbitt> ... as a reminder, here's an overflow of item-flow properties<br> <kbabbitt> ... set of shorthands and longhands that work across all layout systems including flex and grid<br> <kbabbitt> ... will be focusing on item-direction/track + [missed]<br> <kbabbitt> ... first question, what is a row, what is a column?<br> <kbabbitt> ... we have flex-flow property, in flexbox it's standard layout<br> <kbabbitt> ... row looks like rows, and column looks like columns<br> <kbabbitt> ... it also corresponds to how things flow<br> <kbabbitt> ... primary direction<br> <kbabbitt> ... so you can describe row and column keywords using shape it makes as well as flow<br> <kbabbitt> ... in grid, you can have auto-flow row or column<br> <kbabbitt> ... in both cases you can see there are rows or columns respectively<br> <kbabbitt> ... can't distinguish on shape of grid necessarily but flow direction will make a difference<br> <kbabbitt> ... in g-a-f: row, items flow left to right, in column items flow top to bottom<br> <kbabbitt> ... for masonry, you look at this layout and it's more confusing because you have columns or rows depending on style of masonry, but the placement of the items is the opposite of that<br> <kbabbitt> ... this is the distinguishing characteristic of masonry: shape and flow are opposite<br> <kbabbitt> ... question for us is, is a waterfall masonry item-flow row or is it item-flow column?<br> <kbabbitt> ... before we get to anything else, irc poll:<br> <djmarland> a<br> <lea> A<br> <alisonmaher> B<br> <TabAtkins> b<br> <romain> a<br> <dbaron> B<br> <castastrophe> b<br> <bkardell> a<br> <keithamus> A<br> <oriol> b<br> <Kurt> b<br> <florian> B<br> <diekus> b<br> <kbabbitt> POLL: Is a "waterfall masonry" (A) item-flow: row or (B) item-flow: column?<br> <emilio> A<br> <dholbert> B<br> <kbabbitt> B<br> <SebastianZ> B<br> <kizu> A<br> <noamr> a<br> <ChrisL> a<br> <ydaniv> a<br> <miriam> a<br> <lea> The fact that the answers are so split makes me wonder if `item-flow` is the right nomenclature…<br> <kbabbitt> astearns: looks fairly even<br> <rachelandrew> a<br> <kbabbitt> fantasai: let's talk about reversing<br> <kbabbitt> florian: I voted one way then thought more and was less sure<br> <dbaron> (I think currently 12A, 11B)<br> <kbabbitt> ... if you ask is it row or column I give one answer<br> <castastrophe> I'm in sort of the same boat as florian too<br> <kbabbitt> ... if you ask is it item-flow I go the other way<br> <dholbert> (same yeah)<br> <kbabbitt> fantasai: we'll come back to this<br> <kbabbitt> ... reversing:<br> <kbabbitt> ... flexbox has a flex-flow shorthand with direction and wrap<br> <dholbert> (there's a difference between "how do you place consecutive items" vs. "what are the constructs that you see")<br> <kbabbitt> ... these each have reversing keywords which do different things<br> <kbabbitt> ... flex-flow: row-reverse and column-reverse reverse placement in main axis<br> <kbabbitt> ... wrap-reverse reverses stacking of lines<br> <kbabbitt> ... in grid we have grid axis and stacking axis reversal<br> <kbabbitt> ... next question is: does wrap-reverse reverse grid axis or stacking axis?<br> <dholbert> B<br> <bkardell> b<br> <kbabbitt> POLL: Does wrap-reverse reverse (A) the grid axis or (B) the stacking axis?<br> <ydaniv> b<br> <keithamus> A<br> <SebastianZ> B<br> <dbaron> B<br> <astearns> b<br> <kbabbitt> neither makes sense to me<br> <romain> a<br> <TabAtkins> neutral<br> <castastrophe> A<br> <djmarland> b - if the previous question is a<br> <alisonmaher> I don't think it makes sense to ever reverse the stacking axis in masonry<br> <lea> agree with florian<br> <kbabbitt> florian: I think I'm making sense of this but not sure, what about state before reversal?<br> <astearns> wrap is a much less sensible term for masonry<br> <kbabbitt> fantasai: [shows state on slide]<br> <lea> I think I need more time to process these and have an opinion<br> <kbabbitt> miriam: I can't get my mind to wrap around how A and B translate<br> <kbabbitt> miriam: wrap-reverse changes stacking axis<br> <kbabbitt> fantasai: that would be B<br> <miriam> b<br> <kbabbitt> TabAtkins: so wrap-reverse gets the reversal behavior on the right, correct miriam?<br> <kbabbitt> miriam: yes<br> <florian> unsure, but maybe a<br> <oriol> b<br> <kbabbitt> astearns: Poll so far is still divided but definitely more Bs<br> <kbabbitt> fantasai: longhand value space<br> <dbaron> (9B, 3A so far, some with qualifications)<br> <kbabbitt> ... going back to flex properties, we have direction and wrap<br> <dbaron> oops, 9B, 4A<br> <kbabbitt> ... we have item-* properties, might change name<br> <kbabbitt> ... we want to do some auto behavior by default<br> <kbabbitt> ... auto keyword means row in flex layout and also in grid<br> <kbabbitt> ... haven't decided yet in masonry but it should mean brick if g-t-r is set, and g-t-c is not<br> <kbabbitt> ... waterfall in masonry if g-t-c is set, or neither/both are set<br> <kbabbitt> ... most authors will rarely need to choose row or column, we'll try to do the right thing<br> <kbabbitt> ... also question of whether it's auto or normal<br> <kbabbitt> ... in order to unify all this we need an auto keyword since flex doesn't wrap by default<br> <kbabbitt> ... property names:<br> <kbabbitt> ... so far for properties that exist, we have flex-flow and grid-auto-flow and [missed]<br> <kbabbitt> ... grid-auto-flow and flex-flow already exist<br> <kbabbitt> ... flex-flow has direction and wrap longhands<br> <kbabbitt> ... our initial proposal for item-flow was to use flex-flow model and change prefix<br> <kbabbitt> ... depending on what interpretation we want for row and column we might want different names to emphasize<br> <kbabbitt> ... would be confusing potentially to have item-direction, row-direction which is instead shape<br> <kbabbitt> ... [shows overview of all item-* properties together]<br> <kbabbitt> ... another proposal was instead of using item as prefix, use flow<br> <kbabbitt> ... and have flow be the shorthand<br> <kbabbitt> ... downside is that display: flow does not correspond to this set of properties<br> <kbabbitt> ... but makes more sense for flow-tolerance than item-tolerance<br> <kbabbitt> ... on property names, we have two sets of options<br> <TabAtkins> D, a<br> <kbabbitt> ... which set of names should we go with for orientation, wrappping, and reversing controls?<br> <lea> A or C. -track and -cross make no sense to me<br> <florian> a?<br> <djmarland> A<br> <kbabbitt> ... option D would depend on which outcome we have, would be B or A<br> <castastrophe> A<br> <rachelandrew> A<br> <keithamus> A<br> <romain> A<br> <kbabbitt> ... -track would map to direction properties, -cross would map to -wrap properties<br> <SebastianZ> A<br> <celestepan> A or C<br> <kbabbitt> fantasai: so item-track or item-cross<br> <astearns> A for re-using existing concepts, but B seems interesting<br> <ChrisL> abstain, am not following, sorry<br> <kbabbitt> dholbert: item-track: row and item-cross: wrap?<br> <miriam> a/d<br> <kbabbitt> fantasai: yes<br> <dbaron> abstain<br> <kbabbitt> astearns: poll seems to be for A<br> <alisonmaher> neutral<br> <kbabbitt> ... though I wonder whether this is an entirely new idea<br> <kbabbitt> abstain, I'm spending too much brainpower on scribing to consider the options<br> <kbabbitt> fantasai: do we like item-flow to unify these properties or do we want something else?<br> <dholbert> (neutral on that previous poll, but I need to think more)<br> <kbabbitt> lea: might we need to specify flow that is not item-flow on the future?<br> <castastrophe> A<br> <keithamus> A<br> <astearns> a<br> <kbabbitt> fantasai: yes<br> <SebastianZ> A<br> <dbaron> abstain, I'm having trouble following without flipping back through the slides<br> <kbabbitt> lea: in other properties we've used [missed] rather than self<br> <kbabbitt> TabAtkins: yes the entire set of layout keywords we've talked about previously<br> <kbabbitt> [crosstalk]<br> <kbabbitt> TabAtkins: no these are the first<br> <lea> B or C<br> <oriol> Is there a link for the slides?<br> <kbabbitt> abstain<br> <djmarland> A (though I don't mind B as it is manipulating the CSS "Flow" layout)<br> <lea> actually, abstrain for me too<br> <alisonmaher> B<br> <SebastianZ> Regarding 'tolerance', we could still have 'flow' in the name but the prefix would still be 'item', i.e. 'item-flow-tolerance'.<br> <romain> A or C (can "item-flow-" be the prefix?)<br> <dholbert> s/we've used [missed] rather than self/we've used *-self and *-items for property-naming rather than item-/<br> <celestepan> C<br> <miriam> not sure, since the b options aren't really fleshed out. I'm interested in b<br> <kbabbitt> fantasai: another topic: aliasing vs shorthanding<br> <kbabbitt> ... goal with this is to unify flex-flow and grid-auto-flow<br> <javierct> C<br> <kbabbitt> ... 3 ways to do it<br> <kbabbitt> ... aliasing them all to each other<br> <kbabbitt> ... with that we were concerned people might have code that expects flex properties don't affect grid or vice-versa<br> <kbabbitt> ... other option is to shorthand existing properties<br> <kbabbitt> ... item-flow would shorthand grid-auto-flow and flex-flow which remain independent<br> <kbabbitt> ... grid-auto-flow expands to grid-auto-direction and grid-auto-wrap and item-pack<br> <kbabbitt> ... would create item-direction and item-wrap which shorthand the corresponding grid- and flex- longhands<br> <kbabbitt> ... grid-auto-flow controls grid and masonry<br> <kbabbitt> ... third option is like option 2 except create a new set of longhands for masonry<br> <kbabbitt> ... which we were trying to avoid with item-flow<br> <kbabbitt> ... my expectation is we'll go with option 2<br> <djmarland> When people switch from flex to grid in media queries, they may have some leftover properties around they weren't expecting to still be applied if we used aliasing<br> <lea> Slight preference for Option 2. Could be value in being able to set these separately for flex and grid, for generic utility classes, maybe<br> <kbabbitt> ... any clarifying questions?<br> <emilio> q+<br> <Kurt> q+<br> <lea> +1 florian<br> <kbabbitt> florian: i think I understood everything, not sure I digested<br> <astearns> ack emilio<br> <kbabbitt> emilio: more about shorthanding vs not<br> <castastrophe> q+<br> <kbabbitt> ... if we go with 2, it introduces another level of complexity<br> <kbabbitt> ... if you have flex-flow you cannot read item-flow anymore<br> <kbabbitt> ... unless you also have grid expansion<br> <kbabbitt> ... might be a bit finicky, maybe the tradeoff is still better<br> <lea> if we go with Option 1, perhaps we should also deprecate the existing properties rather than just aliasing<br> <astearns> ack Kurt<br> <kbabbitt> Kurt: question, not as familiar with aliasing but going back to that subject, grid shorthand also includes grid-auto-flow, not sure if it's going to be weird to specify grid shorthand and get a bunch of other properties<br> <kbabbitt> ... and override the switch to get masonry<br> <kbabbitt> ... does that introduce weirdness?<br> <kbabbitt> fantasai: don't think so since we're basing masonry on grid<br> <kbabbitt> ... grid shorthand is designed to be completely clean slate for grid layout<br> <kbabbitt> ... if you just want to reset template there's grid-template shorthand<br> <astearns> ack castastrophe<br> <kbabbitt> Kurt: ok just wanted to make sure shorthand is compatible<br> <kbabbitt> castastrophe: visuals are helpful, thank you for putting them together<br> <kbabbitt> ... as we re-poll or determine what our resolution would be, would be helpful to see animations<br> <kbabbitt> ... showing visual change between forward and reverse<br> <kbabbitt> ... to help people solidify understanding of movement and change<br> <kbabbitt> ... would be happy to help with that<br> <kbabbitt> fantasai: happy to go back to slides as well<br> <kbabbitt> ... [shows summary of what was discussed]<br> <kbabbitt> ... illustration of waterfall masonry with grid axis reversed<br> <alisonmaher> q+<br> <astearns> ack alisonmaher<br> <kbabbitt> alisonmaher: question going back to allowing reversal in stacking axis<br> <TabAtkins> q+<br> <kbabbitt> ... curious how that would work, if masonry has indefinite size where would you start from<br> <kbabbitt> ... if definite size, what happens if your items overflow<br> <kbabbitt> ... in flex we'd wrap to create additional lines but in masonry we already set these tracks<br> <kbabbitt> ... would overflow content in opposite direction which is somewhat strange<br> <kbabbitt> fantasai: true that in flexbox we can be reversing and you have same problem of where does it start from<br> <kbabbitt> ... flexbox is also able to grow upwards in that same way<br> <kbabbitt> ... that's the same thing as we'd apply here<br> <kbabbitt> ... so if it's an auto size box it will end up wrapping around the contents of it<br> <kbabbitt> ... if it's fixed size it may overflow off the top edge but we already have rules in flexbox to align in that direction<br> <miriam> q+<br> <kbabbitt> astearns: might be useful to think of the case of a brick style layout in japanese<br> <kbabbitt> ... where the straight lines of masonry are going to be top and right<br> <kbabbitt> ... ragged bit will be to left<br> <TabAtkins> i think the general answer here is "same as flexbox", yeah<br> <kbabbitt> ... is that correct or useful?<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: 2 things about this<br> <kbabbitt> ... we had initially a kind of mixed result on which direction is row vs column<br> <kbabbitt> ... indication that it depends on how people think about it<br> <kbabbitt> ... one detail i find important, a waterfall style masonry is defined with grid-template-columns property<br> <kbabbitt> ... explicit placement uses grid-column<br> <alisonmaher> +1<br> <kbabbitt> ... suggests extraordinary strongly to me that this should be called columns<br> <dholbert> +1<br> <kbabbitt> ... would be strange to say item-flow rows, grid-template-columns<br> <kbabbitt> ... item-flow: row should be brick or it would be strange<br> <dholbert> (especially given that visually there are no rows)<br> <kbabbitt> ... secondly, when fantasai and I were chatting about this and revising slides yesterday<br> <dholbert> (in a waterfall-style layout)<br> <kbabbitt> ... she brought up a possibility I hadn't considered for reversing keywords<br> <kbabbitt> ... option C on this slide<br> <kbabbitt> ... which is, in this example, assuming it's called columns, using the column-reverse keyword to indicate not flowing in reverse along columns but instead indicating stacking the columns in reverse as shown in this picture would make the wrap-reverse keyword make more sense<br> <kbabbitt> ... because that only triggers when you have filled up all the spaces and are resetting to find new spots to fill<br> <kbabbitt> ... vaguely similar to wrapping a line<br> <kbabbitt> ... that would indicate that this example on screen would be called a column-reverse masonry<br> <kbabbitt> ... does mean that what exactly the reverse is going with is different than flexbox<br> <kbabbitt> ... but direction and wrap properties make more sense for it<br> <kbabbitt> ... lessens need I felt previouisly for generic names<br> <kbabbitt> ... none of those options sounded good<br> <kbabbitt> ... encouraged by anything that lets us use direction and wrap, already established, make sense<br> <astearns> ack miriam<br> <kbabbitt> miriam: caveat by saying I'm dyslexic and all of this messes me up, but I get confused already with grid-auto-flow defaulting to rows, but grid defaults to giving me column<br> <kbabbitt> ... understand why it's called row and if there are more columns row will fill up first before we wrap<br> <kbabbitt> ... but it's already not what I expect<br> <TabAtkins> Oh, if it's a completely undefined grid, so it just puts one item in the first row, then immediately wraps to a second row, then a third<br> <kbabbitt> ... when I set grid-auto-flow-row<br> <kbabbitt> ... so hard to think what my mind expects on first reaction as useful somehow here<br> <lea> not dyslexic and have the same issue as miriam with existing grid-auto-flow<br> <kbabbitt> ... already we're talking about something different from what my mind expects<br> <djmarland> q+<br> <astearns> ack djmarland<br> <kbabbitt> djmarland: coming at it from the angle of where is my next item going<br> <fantasai> Slides: https://lists.w3.org/Archives/Public/www-archive/2025Oct/att-0013/CSSWG_2025_October_Masonry_Item_Flow.pdf<br> <kbabbitt> ... felt like it's going along rows, that led me to thiniking that direction<br> <kbabbitt> TabAtkins: taht's the argument for making waterfall be rows<br> <kbabbitt> ... only applies for first couple of items, then it jumps around<br> <florian> q+<br> <lea> typically when people are confused with `property-name: row | column`, it suggests that the problem is `property-name`, and focusing on whether to pick `row` or `column` is a red herring<br> <astearns> ack florian<br> <kbabbitt> florian: only a partial answer to this, but I'm among the many who didn't like -track and -cross<br> <kbabbitt> ... thinking more about it, it's the -cross part I didn't like<br> <kbabbitt> ... track made sense and might work if it got a better friend<br> <kbabbitt> TabAtkins: any help with better name, I'd be happy with that<br> <kbabbitt> ... took name of cross direction to be other part<br> <TabAtkins> What I think I'm really getting out of this is that people do *not* have strong intuitions for how all this works, so we can go ahead and just make something internal consistent that works for us.<br> <lea> q+<br> <kbabbitt> florian: don't have a better alternative but think -cross is the problem, track might actually work<br> <astearns> ack lea<br> <kbabbitt> lea: I find both cross and track confusing<br> <kbabbitt> ... cross axis is something that confuxes people with flexbox as well<br> <kbabbitt> .. what to pick justify-content and align-items for<br> <kbabbitt> ... that's a continunous point of confusion<br> <kbabbitt> ,.. distinction we have here is, what items are aligned<br> <kbabbitt> ... along which axis are items aligned, or dimensions equalized<br> <kbabbitt> ... and in which axis they're placed<br> <kbabbitt> ... I wonder if there's some kind of naming around that<br> <kbabbitt> ... if so many people are divided and confused about what row and column mean, answer is not to decide whether to go row and column but whether there's a better name for property<br> <kbabbitt> ... still need to do design work around names of properties<br> <miriam> flex-flow: row, you get a row by default. grid-auto-flow: row, you get a column by default… 😅<br> <kbabbitt> fantasai: TabAtkins and I have been trying and haven't come up with anything<br> <kbabbitt> TabAtkins: need better ideas or need to go with something<br> <kbabbitt> astearns: anyone else?<br> <kbabbitt> florian: I prefer auto rather than normal<br> <kbabbitt> ... but wouldn't mind other way around if others insist<br> <kbabbitt> astearns: also in the auto camp<br> <castastrophe> +1<br> <kbabbitt> ... are there resolutions we can take for this issue?<br> <kbabbitt> fantasai: doesn't sound like it<br> <kbabbitt> ... but this is a significantly blocking issue so we should try to get it resolved soon<br> <kbabbitt> TabAtkins: all of these issues are strict shipping blockers, core issues, need to decide to ship masonry<br> <kbabbitt> lea: slide deck helps explain, I'm hoping if people can sit with it for a week or so, we'll have more to discuss next week<br> <kbabbitt> florian: I'd like to thank not just fantasai for doing presentation but for presenting in fair and unbiased way<br> <kbabbitt> ... having done that, do you have a preference?<br> <kbabbitt> TabAtkins: between the two of us? no<br> <kbabbitt> fantasai: we have some thoughts on what people are most unhappy with<br> <kbabbitt> ... I think TabAtkins is most unhappy with waterfall layout not being called columns<br> <kbabbitt> ... i would be most unhappy if we were inconsistent with flexbox naming<br> <kbabbitt> TabAtkins: I'm unhappy about not using column for waterfall probably to point of formal objection<br> <kbabbitt> ... everything else I'm flexible on<br> <kbabbitt> astearns: did you say opposite things?<br> <kbabbitt> TabAtkins: we disagree with each other, correct<br> <kbabbitt> florian: clarifying question TabAtkins, is that regardless of property name?<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> ... I could accept less optimal property names if that got us waterfall being called columns<br> <kbabbitt> florian: to me waterfall was obviously column, then I looked at property name and it was less obvious<br> <miriam> +1 florian<br> <kbabbitt> +1 florian<br> <kbabbitt> astearns: sit on this issue for another week and bring back to agenda?<br> <kbabbitt> fantasai: we can open discussion on next issue<br> <kbabbitt> florian: people should do more than sit on this, we need active thinking<br> <kbabbitt> fantasai: I posted a link to slides in issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3433291143 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 October 2025 16:43:42 UTC