15:59:15 <RRSAgent> RRSAgent has joined #css
15:59:20 <RRSAgent> logging to https://www.w3.org/2025/10/22-css-irc
15:59:20 <Zakim> RRSAgent, make logs Public
15:59:21 <bts> bts has joined #css
15:59:21 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:59:35 <SebastianZ> present+
15:59:37 <romain> present+
15:59:44 <kizu> present+
15:59:45 <lea> present+
15:59:46 <kbabbitt> kbabbitt has joined #css
15:59:58 <ydaniv> ydaniv has joined #css
16:00:23 <bts> present+
16:00:37 <dholbert> dholbert has joined #css
16:00:46 <djmarland> djmarland has joined #css
16:01:16 <bkardell> bkardell has joined #css
16:01:26 <noamr> noamr has joined #css
16:01:27 <castastrophe> castastrophe has joined #css
16:01:30 <ydaniv> present+
16:01:33 <dbaron> Present+
16:01:33 <noamr> present+
16:01:35 <kbabbitt> present
16:01:36 <kbabbitt> present+
16:01:37 <ChrisL> present+
16:01:40 <Kurt> Kurt has joined #css
16:01:41 <kbabbitt> scribenick: kbabbitt
16:01:42 <jfkthame> jfkthame has joined #css
16:02:01 <TabAtkins> present+
16:02:02 <kbabbitt> Topic: Presentation on masonry
16:02:09 <Kurt> present+
16:02:17 <jfkthame> present+
16:02:41 <castastrophe> present+
16:02:42 <alisonmaher> alisonmaher has joined #css
16:02:46 <castastrophe> Hope this isn’t inappropriate to mention, but next week is my last week at Adobe and I’m available for hire after that. 🙂
16:02:48 <alisonmaher> present+
16:02:48 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12803
16:02:49 <github-bot> Topic: [css-grid-3][masonry] item-flow row vs. column in masonry layouts
16:02:49 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12803.
16:03:09 <rachelandrew> present+
16:03:15 <smfr> smfr has joined #css
16:03:16 <kbabbitt> fantasai: [presents slides]
16:03:23 <bkardell> present+
16:03:26 <kbabbitt> fantasai: talking about masonry and item-flow
16:03:40 <kbabbitt> ... we ran polls to get impressions at various moments of time
16:03:49 <diekus> diekus has joined #css
16:03:53 <kbabbitt> ... sections will end up interacting, once we're done with review I'll open for questions
16:04:04 <kbabbitt> ... as a reminder, here's an overflow of item-flow properties
16:04:15 <kbabbitt> ... set of shorthands and longhands that work across all layout systems including flex and grid
16:04:26 <kbabbitt> ... will be focusing on item-direction/track + [missed]
16:04:30 <kbabbitt> ... first question, what is a row, what is a column?
16:04:41 <kbabbitt> ... we have flex-flow property, in flexbox it's standard layout
16:04:51 <kbabbitt> ... row looks like rows, and column looks like columns
16:04:56 <kbabbitt> ... it also corresponds to how things flow
16:05:00 <kbabbitt> ... primary direction
16:05:00 <oriol> present+
16:05:10 <kbabbitt> ... so you can describe row and column keywords using shape it makes as well as flow
16:05:17 <kbabbitt> ... in grid, you can have auto-flow row or column
16:05:24 <kbabbitt> ... in both cases you can see there are rows or columns respectively
16:05:38 <kbabbitt> ... can't distinguish on shape of grid necessarily but flow direction will make a difference
16:05:53 <kbabbitt> ... in g-a-f: row, items flow left to right, in column items flow top to bottom
16:05:54 <djmarland> present+
16:06:18 <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
16:06:28 <kbabbitt> ... this is the distinguishing characteristic of masonry: shape and flow are opposite
16:06:39 <kbabbitt> ... question for us is, is a waterfall masonry item-flow row or is it item-flow column?
16:06:48 <kbabbitt> ... before we get to anything else, irc poll:
16:06:52 <djmarland> a
16:06:55 <lea> A
16:06:55 <alisonmaher> B
16:06:56 <TabAtkins> b
16:06:58 <romain> a
16:06:59 <dbaron> B
16:06:59 <castastrophe> b
16:06:59 <bkardell> a
16:06:59 <keithamus> A
16:07:00 <oriol> b
16:07:01 <Kurt> b
16:07:01 <florian> B
16:07:01 <diekus> b
16:07:14 <javierct> javierct has joined #css
16:07:15 <kbabbitt> POLL: Is a "waterfall masonry" (A) item-flow: row or (B) item-flow: column?
16:07:15 <emilio> A
16:07:20 <dholbert> B
16:07:22 <kbabbitt> B
16:07:22 <SebastianZ> B
16:07:25 <kizu> A
16:07:28 <noamr> a
16:07:35 <ChrisL> a
16:07:36 <ydaniv> a
16:07:37 <miriam> a
16:07:43 <fantasai> fantasai has joined #css
16:07:43 <lea> The fact that the answers are so split makes me wonder if `item-flow` is the right nomenclature…
16:07:46 <kbabbitt> astearns: looks fairly even
16:07:53 <miriam> present+
16:07:54 <rachelandrew> a
16:08:00 <kbabbitt> fantasai: let's talk about reversing
16:08:09 <kbabbitt> florian: I voted one way then thought more and was less sure
16:08:11 <dbaron> (I think currently 12A, 11B)
16:08:15 <kbabbitt> ... if you ask is it row or column I give one answer
16:08:18 <bts6> bts6 has joined #css
16:08:22 <castastrophe> I'm in sort of the same boat as florian too
16:08:23 <kbabbitt> ... if you ask is it item-flow I go the other way
16:08:25 <dholbert> (same yeah)
16:08:27 <kbabbitt> fantasai: we'll come back to this
16:08:30 <kbabbitt> ... reversing:
16:08:40 <kbabbitt> ... flexbox has a flex-flow shorthand with direction and wrap
16:08:44 <dholbert> (there's a difference between "how do you place consecutive items" vs. "what are the constructs that you see")
16:08:47 <kbabbitt> ... these each have reversing keywords which do different things
16:09:07 <kbabbitt> ... flex-flow: row-reverse and column-reverse reverse placement in main axis
16:09:16 <kbabbitt> ... wrap-reverse reverses stacking of lines
16:09:33 <kbabbitt> ... in grid we have grid axis and stacking axis reversal
16:09:48 <kbabbitt> ... next question is: does wrap-reverse reverse grid axis or stacking axis?
16:10:06 <dholbert> B
16:10:09 <bkardell> b
16:10:09 <kbabbitt> POLL: Does wrap-reverse reverse (A) the grid axis or (B) the stacking axis?
16:10:13 <ydaniv> b
16:10:16 <keithamus> A
16:10:23 <SebastianZ> B
16:10:58 <dbaron> B
16:11:02 <astearns> b
16:11:06 <kbabbitt> neither makes sense to me
16:11:21 <romain> a
16:11:24 <TabAtkins> neutral
16:11:25 <castastrophe> A
16:11:26 <djmarland> b - if the previous question is a
16:11:36 <alisonmaher> I don't think it makes sense to ever reverse the stacking axis in masonry
16:11:37 <lea> agree with florian
16:11:38 <kbabbitt> florian: I think I'm making sense of this but not sure, what about state before reversal?
16:11:38 <astearns> wrap is a much less sensible term for masonry
16:11:49 <kbabbitt> fantasai: [shows state on slide]
16:11:59 <lea> I think I need more time to process these and have an opinion
16:12:05 <kbabbitt> miriam: I can't get my mind to wrap around how A and B translate
16:12:14 <kbabbitt> miriam: wrap-reverse changes stacking axis
16:12:18 <kbabbitt> fantasai: that would be B
16:12:19 <miriam> b
16:12:36 <kbabbitt> TabAtkins: so wrap-reverse gets the reversal behavior on the right, correct miriam?
16:12:38 <kbabbitt> miriam: yes
16:12:43 <florian> unsure, but maybe a
16:12:47 <oriol> b
16:12:49 <kbabbitt> astearns: Poll so far is still divided but definitely more Bs
16:12:55 <kbabbitt> fantasai: longhand value space
16:12:58 <dbaron> (9B, 3A so far, some with qualifications)
16:13:12 <kbabbitt> ... going back to flex properties, we have direction and wrap
16:13:12 <dbaron> oops, 9B, 4A
16:13:17 <kbabbitt> ... we have item-* properties, might change name
16:13:26 <kbabbitt> ... we want to do some auto behavior by default
16:13:33 <kbabbitt> ... auto keyword means row in flex layout and also in grid
16:13:51 <kbabbitt> ... haven't decided yet in masonry but it should mean brick if g-t-r is set, and g-t-c is not
16:14:02 <kbabbitt> ... waterfall in masonry if g-t-c is set, or neither/both are set
16:14:16 <kbabbitt> ... most authors will rarely need to choose row or column, we'll try to do the right thing
16:14:21 <kbabbitt> ... also question of whether it's auto or normal
16:14:33 <kbabbitt> ... in order to unify all this we need an auto keyword since flex doesn't wrap by default
16:14:38 <kbabbitt> ... property names:
16:14:52 <kbabbitt> ... so far for properties that exist, we have flex-flow and grid-auto-flow and [missed]
16:15:20 <kbabbitt> ... grid-auto-flow and flex-flow already exist
16:15:27 <kbabbitt> ... flex-flow has direction and wrap longhands
16:15:29 <celestepan> celestepan has joined #css
16:15:36 <kbabbitt> ... our initial proposal for item-flow was to use flex-flow model and change prefix
16:15:49 <kbabbitt> ... depending on what interpretation we want for row and column we might want different names to emphasize
16:16:01 <kbabbitt> ... would be confusing potentially to have item-direction, row-direction which is instead shape
16:16:15 <kbabbitt> ... [shows overview of all item-* properties together]
16:16:23 <kbabbitt> ... another proposal was instead of using item as prefix, use flow
16:16:26 <kbabbitt> ... and have flow be the shorthand
16:16:38 <kbabbitt> ... downside is that display: flow does not correspond to this set of properties
16:16:47 <kbabbitt> ... but makes more sense for flow-tolerance than item-tolerance
16:17:09 <kbabbitt> ... on property names, we have two sets of options
16:17:32 <TabAtkins> D, a
16:17:34 <kbabbitt> ... which set of names should we go with for orientation, wrappping, and reversing controls?
16:17:37 <lea> A or C. -track and -cross make no sense to me
16:17:50 <florian> a?
16:17:53 <djmarland> A
16:17:56 <kbabbitt> ... option D would depend on which outcome we have, would be B or A
16:17:57 <castastrophe> A
16:17:58 <rachelandrew> A
16:18:04 <keithamus> A
16:18:11 <romain> A
16:18:12 <kbabbitt> ... -track would map to direction properties, -cross would map to -wrap properties
16:18:21 <SebastianZ> A
16:18:25 <celestepan> A or C
16:18:29 <kbabbitt> fantasai: so item-track or item-cross
16:18:30 <astearns> A for re-using existing concepts, but B seems interesting
16:18:39 <ChrisL> abstain, am not following, sorry
16:18:41 <kbabbitt> dholbert: item-track: row and item-cross: wrap?
16:18:43 <miriam> a/d
16:18:44 <kbabbitt> fantasai: yes
16:18:53 <dbaron> abstain
16:18:53 <kbabbitt> astearns: poll seems to be for A
16:18:59 <alisonmaher> neutral
16:19:00 <kbabbitt> ... though I wonder whether this is an entirely new idea
16:19:14 <kbabbitt> abstain, I'm spending too much brainpower on scribing to consider the options
16:19:31 <kbabbitt> fantasai: do we like item-flow to unify these properties or do we want something else?
16:19:35 <dholbert> (neutral on that previous poll, but I need to think more)
16:19:40 <kbabbitt> lea: might we need to specify flow that is not item-flow on the future?
16:19:40 <castastrophe> A
16:19:41 <keithamus> A
16:19:42 <astearns> a
16:19:45 <kbabbitt> fantasai: yes
16:19:47 <SebastianZ> A
16:19:49 <dbaron> abstain, I'm having trouble following without flipping back through the slides
16:20:02 <kbabbitt> lea: in other properties we've used [missed] rather than self
16:20:12 <kbabbitt> TabAtkins: yes the entire set of layout keywords we've talked about previously
16:20:22 <kbabbitt> [crosstalk]
16:20:26 <kbabbitt> TabAtkins: no these are the first
16:20:33 <lea> B or C
16:20:34 <oriol> Is there a link for the slides?
16:20:39 <matthieud> matthieud has joined #css
16:20:39 <kbabbitt> abstain
16:20:46 <djmarland> A (though I don't mind B as it is manipulating the CSS "Flow" layout)
16:20:49 <lea> actually, abstrain for me too
16:20:50 <alisonmaher> B
16:20:54 <SebastianZ> Regarding 'tolerance', we could still have 'flow' in the name but the prefix would still be 'item', i.e. 'item-flow-tolerance'.
16:20:56 <romain> A or C (can "item-flow-" be the prefix?)
16:21:01 <dholbert> s/we've used [missed] rather than self/we've used *-self and *-items for property-naming rather than item-/
16:21:29 <celestepan> C
16:21:41 <miriam> not sure, since the b options aren't really fleshed out. I'm interested in b
16:21:42 <kbabbitt> fantasai: another topic: aliasing vs shorthanding
16:21:49 <kbabbitt> ... goal with this is to unify flex-flow and grid-auto-flow
16:21:51 <javierct> C
16:21:52 <kbabbitt> ... 3 ways to do it
16:21:57 <kbabbitt> ... aliasing them all to each other
16:22:38 <kbabbitt> ... with that we were concerned people might have code that expects flex properties don't affect grid or vice-versa
16:22:44 <kbabbitt> ... other option is to shorthand existing properties
16:22:54 <kbabbitt> ... item-flow would shorthand grid-auto-flow and flex-flow which remain independent
16:23:06 <kbabbitt> ... grid-auto-flow expands to grid-auto-direction and grid-auto-wrap and item-pack
16:23:21 <kbabbitt> ... would create item-direction and item-wrap which shorthand the corresponding grid- and flex- longhands
16:23:26 <kbabbitt> ... grid-auto-flow controls grid and masonry
16:23:39 <kbabbitt> ... third option is like option 2 except create a new set of longhands for masonry
16:23:45 <kbabbitt> ... which we were trying to avoid with item-flow
16:23:51 <kbabbitt> ... my expectation is we'll go with option 2
16:23:53 <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
16:23:54 <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
16:24:00 <kbabbitt> ... any clarifying questions?
16:24:04 <emilio> q+
16:24:13 <Kurt> q+
16:24:14 <lea> +1 florian
16:24:14 <kbabbitt> florian: i think I understood everything, not sure I digested
16:24:19 <astearns> ack emilio
16:24:21 <kbabbitt> emilio: more about shorthanding vs not
16:24:28 <castastrophe> q+
16:24:31 <kbabbitt> ... if we go with 2, it introduces another level of complexity
16:24:38 <kbabbitt> ... if you have flex-flow you cannot read item-flow anymore
16:24:42 <kbabbitt> ... unless you also have grid expansion
16:24:52 <kbabbitt> ... might be a bit finicky, maybe the tradeoff is still better
16:25:02 <lea> if we go with Option 1, perhaps we should also deprecate the existing properties rather than just aliasing
16:25:10 <astearns> ack Kurt
16:25:33 <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
16:25:37 <kbabbitt> ... and override the switch to get masonry
16:25:45 <kbabbitt> ... does that introduce weirdness?
16:25:54 <kbabbitt> fantasai: don't think so since we're basing masonry on grid
16:26:03 <kbabbitt> ... grid shorthand is designed to be completely clean slate for grid layout
16:26:12 <kbabbitt> ... if you just want to reset template there's grid-template shorthand
16:26:18 <astearns> ack castastrophe
16:26:20 <kbabbitt> Kurt: ok just wanted to make sure shorthand is compatible
16:26:31 <kbabbitt> castastrophe: visuals are helpful, thank you for putting them together
16:26:40 <kbabbitt> ... as we re-poll or determine what our resolution would be, would be helpful to see animations
16:26:46 <kbabbitt> ... showing visual change between forward and reverse
16:26:55 <kbabbitt> ... to help people solidify understanding of movement and change
16:26:59 <kbabbitt> ... would be happy to help with that
16:27:05 <kbabbitt> fantasai: happy to go back to slides as well
16:27:23 <kbabbitt> ... [shows summary of what was discussed]
16:27:33 <sgill> sgill has joined #css
16:27:34 <kbabbitt> ... illustration of waterfall masonry with grid axis reversed
16:27:35 <alisonmaher> q+
16:27:43 <astearns> ack alisonmaher
16:27:47 <kbabbitt> alisonmaher: question going back to allowing reversal in stacking axis
16:27:49 <TabAtkins> q+
16:27:57 <kbabbitt> ... curious how that would work, if masonry has indefinite size where would you start from
16:28:03 <kbabbitt> ... if definite size, what happens if your items overflow
16:28:13 <kbabbitt> ... in flex we'd wrap to create additional lines but in masonry we already set these tracks
16:28:21 <kbabbitt> ... would overflow content in opposite direction which is somewhat strange
16:28:35 <kbabbitt> fantasai: true that in flexbox we can be reversing and you have same problem of where does it start from
16:28:45 <kbabbitt> ... flexbox is also able to grow upwards in that same way
16:28:49 <kbabbitt> ... that's the same thing as we'd apply here
16:29:01 <kbabbitt> ... so if it's an auto size box it will end up wrapping around the contents of it
16:29:13 <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
16:29:19 <miriam> q+
16:29:23 <kbabbitt> astearns: might be useful to think of the case of a brick style layout in japanese
16:29:32 <kbabbitt> ... where the straight lines of masonry are going to be top and right
16:29:38 <kbabbitt> ... ragged bit will be to left
16:29:39 <TabAtkins> i think the general answer here is "same as flexbox", yeah
16:29:42 <kbabbitt> ... is that correct or useful?
16:29:59 <astearns> ack TabAtkins
16:30:01 <kbabbitt> TabAtkins: 2 things about this
16:30:11 <kbabbitt> ... we had initially a kind of mixed result on which direction is row vs column
16:30:17 <kbabbitt> ... indication that it depends on how people think about it
16:30:31 <kbabbitt> ... one detail i find important, a waterfall style masonry is defined with grid-template-columns property
16:30:36 <kbabbitt> ... explicit placement uses grid-column
16:30:42 <alisonmaher> +1
16:30:48 <kbabbitt> ... suggests extraordinary strongly to me that this should be called columns
16:30:58 <dholbert> +1
16:31:03 <kbabbitt> ... would be strange to say item-flow rows, grid-template-columns
16:31:12 <kbabbitt> ... item-flow: row should be brick or it would be strange
16:31:15 <dholbert> (especially given that visually there are no rows)
16:31:28 <kbabbitt> ... secondly, when fantasai and I were chatting about this and revising slides yesterday
16:31:29 <dholbert> (in a waterfall-style layout)
16:31:38 <kbabbitt> ... she brought up a possibility I hadn't considered for reversing keywords
16:31:40 <kbabbitt> ... option C on this slide
16:32:12 <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
16:32:24 <kbabbitt> ... because that only triggers when you have filled up all the spaces and are resetting to find new spots to fill
16:32:29 <kbabbitt> ... vaguely similar to wrapping a line
16:32:39 <kbabbitt> ... that would indicate that this example on screen would be called a column-reverse masonry
16:32:53 <kbabbitt> ... does mean that what exactly the reverse is going with is different than flexbox
16:32:59 <kbabbitt> ... but direction and wrap properties make more sense for it
16:33:06 <kbabbitt> ... lessens need I felt previouisly for generic names
16:33:10 <kbabbitt> ... none of those options sounded good
16:33:27 <kbabbitt> ... encouraged by anything that lets us use direction and wrap, already established, make sense
16:33:28 <astearns> ack miriam
16:33:58 <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
16:34:12 <kbabbitt> ... understand why it's called row and if there are more columns row will fill up first before we wrap
16:34:18 <kbabbitt> ... but it's already not what I expect
16:34:21 <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
16:34:23 <kbabbitt> ... when I set grid-auto-flow-row
16:34:32 <kbabbitt> ... so hard to think what my mind expects on first reaction as useful somehow here
16:34:38 <lea> not dyslexic and have the same issue as miriam with existing grid-auto-flow
16:34:41 <kbabbitt> ... already we're talking about something different from what my mind expects
16:34:48 <djmarland> q+
16:35:03 <astearns> ack djmarland
16:35:04 <kbabbitt> djmarland: coming at it from the angle of where is my next item going
16:35:15 <fantasai> Slides: https://lists.w3.org/Archives/Public/www-archive/2025Oct/att-0013/CSSWG_2025_October_Masonry_Item_Flow.pdf
16:35:17 <kbabbitt> ... felt like it's going along rows, that led me to thiniking that direction
16:35:24 <kbabbitt> TabAtkins: taht's the argument for making waterfall be rows
16:35:32 <kbabbitt> ... only applies for first couple of items, then it jumps around
16:35:33 <florian> q+
16:35:37 <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
16:35:47 <astearns> ack florian
16:35:51 <kbabbitt> florian: only a partial answer to this, but I'm among the many who didn't like -track and -cross
16:35:59 <kbabbitt> ... thinking more about it, it's the -cross part I didn't like
16:36:07 <kbabbitt> ... track made sense and might work if it got a better friend
16:36:17 <kbabbitt> TabAtkins: any help with better name, I'd be happy with that
16:36:23 <kbabbitt> ... took name of cross direction to be other part
16:36:28 <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.
16:36:31 <lea> q+
16:36:34 <kbabbitt> florian: don't have a better alternative but think -cross is the problem, track might actually work
16:36:38 <astearns> ack lea
16:36:45 <kbabbitt> lea: I find both cross and track confusing
16:36:54 <kbabbitt> ... cross axis is something that confuxes people with flexbox as well
16:37:01 <kbabbitt> .. what to pick justify-content and align-items for
16:37:05 <kbabbitt> ... that's a continunous point of confusion
16:37:15 <kbabbitt> ,.. distinction we have here is, what items are aligned
16:37:23 <kbabbitt> ... along which axis are items aligned, or dimensions equalized
16:37:27 <kbabbitt> ... and in which axis they're placed
16:37:34 <kbabbitt> ... I wonder if there's some kind of naming around that
16:37:55 <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
16:38:01 <kbabbitt> ... still need to do design work around names of properties
16:38:15 <miriam> flex-flow: row, you get a row by default. grid-auto-flow: row, you get a column by default… 😅
16:38:18 <kbabbitt> fantasai: TabAtkins and I have been trying and haven't come up with anything
16:38:25 <kbabbitt> TabAtkins: need better ideas or need to go with something
16:38:36 <kbabbitt> astearns: anyone else?
16:38:45 <kbabbitt> florian: I prefer auto rather than normal
16:38:54 <kbabbitt> ... but wouldn't mind other way around if others insist
16:38:58 <kbabbitt> astearns: also in the auto camp
16:39:01 <castastrophe> +1
16:39:05 <kbabbitt> ... are there resolutions we can take for this issue?
16:39:13 <kbabbitt> fantasai: doesn't sound like it
16:39:25 <kbabbitt> ... but this is a significantly blocking issue so we should try to get it resolved soon
16:39:42 <kbabbitt> TabAtkins: all of these issues are strict shipping blockers, core issues, need to decide to ship masonry
16:39:56 <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
16:40:11 <kbabbitt> florian: I'd like to thank not just fantasai for doing presentation but for presenting in fair and unbiased way
16:40:18 <kbabbitt> ... having done that, do you have a preference?
16:40:22 <kbabbitt> TabAtkins: between the two of us? no
16:40:31 <kbabbitt> fantasai: we have some thoughts on what people are most unhappy with
16:40:43 <kbabbitt> ... I think TabAtkins is most unhappy with waterfall layout not being called columns
16:40:52 <kbabbitt> ... i would be most unhappy if we were inconsistent with flexbox naming
16:41:08 <kbabbitt> TabAtkins: I'm unhappy about not using column for waterfall probably to point of formal objection
16:41:13 <kbabbitt> ... everything else I'm flexible on
16:41:18 <kbabbitt> astearns: did you say opposite things?
16:41:25 <kbabbitt> TabAtkins: we disagree with each other, correct
16:41:50 <kbabbitt> florian: clarifying question TabAtkins, is that regardless of property name?
16:41:52 <kbabbitt> TabAtkins: yes
16:42:06 <kbabbitt> ... I could accept less optimal property names if that got us waterfall being called columns
16:42:19 <kbabbitt> florian: to me waterfall was obviously column, then I looked at property name and it was less obvious
16:42:21 <miriam> +1 florian
16:42:25 <kbabbitt> +1 florian
16:42:35 <kbabbitt> astearns: sit on this issue for another week and bring back to agenda?
16:43:03 <kbabbitt> fantasai: we can open discussion on next issue
16:43:13 <kbabbitt> florian: people should do more than sit on this, we need active thinking
16:43:24 <kbabbitt> fantasai: I posted a link to slides in issue
16:43:38 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12804
16:43:38 <github-bot> Topic: [css-grid-3][masonry] Longhand shorthand relationships of item-flow
16:43:38 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12804.
16:43:54 <kbabbitt> astearns: on this one, you said option 2
16:44:37 <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
16:44:45 <kbabbitt> fantasai: it doesn't
16:44:55 <kbabbitt> TabAtkins: in option 2, individual layout modes have their respective properties
16:44:56 <bts> bts has joined #css
16:44:58 <kbabbitt> ... we just have a shorthand for them
16:45:13 <kbabbitt> ... you could read auto-flow but it doesn't transfer over
16:45:27 <kbabbitt> astearns: it's a little weird to have a shorthand when you could set grid and flex separately and have only one apply
16:45:36 <kbabbitt> fantasai: not sure I follow, item-flow sets both
16:45:52 <kbabbitt> florian: but you can't use the shorthand to set grid to one and flex to the other
16:46:06 <kbabbitt> TabAtkins: astearns wasn't asking for that, said it would be confusing if you could
16:46:20 <kbabbitt> fantasai: could design that but would need to be pretty explicit about it
16:46:40 <kbabbitt> ... [writes syntax for it on the slide]
16:46:56 <kbabbitt> ... could consider what happens if you set both independently, not expecting use of this double syntax
16:47:07 <kbabbitt> florian: not convinced we're starting from scratch introducing things
16:47:24 <kbabbitt> ... but we do have them, flex properties don't affect grid, just aliasing everything seems undesirable to impossible
16:47:32 <kbabbitt> ... option 2 has weirdness but others seem worse
16:47:42 <TabAtkins> I like option 2 as long as we can it through ^_^
16:47:44 <kbabbitt> astearns: anyone want to argue against option 2 or suggest alternatives?
16:47:56 <kbabbitt> ... shall we resolve on option 2?
16:48:25 <kbabbitt> astearns: given that preference from both fantasai and TabAtkins and not hearing any opposition, proposed resolution is to go with option 2
16:48:29 <kbabbitt> ... objections?
16:48:33 <kbabbitt> RESOLVED: Go with option 2
16:48:49 <kbabbitt> fantasai: there's only one detail here, if we want item-flow to be able to set different values ...
16:48:56 <kbabbitt> astearns: let's make a note and only get to it if we have to
16:49:16 <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?
16:49:19 <kbabbitt> ... not a representative value
16:49:25 <kbabbitt> TabAtkins: seems fine to me
16:49:34 <kbabbitt> astearns: an alternative would be to preference one or other
16:49:37 <TabAtkins> play stupid games, win stupid prizes
16:49:42 <kbabbitt> miriam: is that not normal or auto?
16:49:54 <kbabbitt> florian: no because if you set it to normal, that would do the weird thing where they disagree
16:49:55 <TabAtkins> item-flow:abnormal
16:50:20 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12022
16:50:20 <github-bot> Topic: [css-grid-3] Masonry Switch Syntax
16:50:20 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12022.
16:50:32 <kbabbitt> fantasai: been a whole lot of names suggested
16:50:38 <kbabbitt> ... you can see all of them in the issue
16:50:49 <kbabbitt> ... pulled out the ones where someone said I agree with this other person
16:51:08 <kbabbitt> ... can break down question into what keyword we want, whether we want spaces, grid first or later
16:51:10 <astearns> no to -ed, imo
16:51:23 <kbabbitt> ... one thing we could do is runoff poll, list up to 4 favorite options, see which ones are worth polling
16:51:27 <florian> q+
16:51:32 <kbabbitt> ... one consideration is, webkit is strongly against using masonry
16:51:39 <kbabbitt> ... for 2 reasons: one it's a jargony
16:51:47 <kbabbitt> ... word, specific to js libraries
16:51:52 <lea> +1 on the rationale against masonry
16:51:53 <kbabbitt> ... not a generally applicable term
16:52:04 <kbabbitt> ... we've been talking about masonry layout forever because we didn't have an alternative term
16:52:23 <kbabbitt> ... second reason is that it's a name that is describing an object in real world that reflects [missed]
16:52:30 <kbabbitt> ... in CSS we try to be more directly descriptive
16:52:40 <kbabbitt> ... we don't talk about gutters, we talk about gaps
16:52:47 <kbabbitt> ... so we feel strongly it should not be masonry
16:53:05 <astearns> q+
16:53:05 <lea> packed-grid or grid-pack are my top preferences as well
16:53:08 <kbabbitt> ... our suggestion was packed-grid
16:53:14 <kbabbitt> ... but there were a bunch of others
16:53:27 <kbabbitt> florian: put myself on queue to say largely the same thing
16:53:29 <alisonmaher> q+
16:53:32 <kbabbitt> ... the one that seems least fine is masonry
16:53:35 <astearns> ack florian
16:53:37 <oriol> q+
16:53:42 <kbabbitt> ... only reason it's agreeable is it's the word we've been using
16:53:51 <kbabbitt> ... if it weren't for that library we wouldn't use it
16:53:52 <miriam> q+
16:53:58 <kbabbitt> ... wouldn't formally object but dislike it
16:54:10 <kbabbitt> astearns: probably object to staggered, too hard to spell
16:54:13 <kbabbitt> ... preference for grid-stack
16:54:20 <TabAtkins> I'm also okay with most of these names, but I lean toward grid-stack as my preference because it matches so well to the "grid axis" and "stacking axis" terms that we settled on in the spec - I think those are *good* terms.
16:54:21 <lea> stack makes me personally think of stacking along the Z axis
16:54:25 <kbabbitt> ... since they have grid like behavior in one axis and stacking in other, if we can't do masonry
16:54:28 <SebastianZ> +1 on astearns
16:54:33 <astearns> ack astearns
16:54:40 <kbabbitt> alisonmaher: one reason I don't like packed-grid is that there's already dense packing in masonry as well as grid
16:54:44 <astearns> +1 to that problem with pack, forgot to mention it
16:54:45 <kbabbitt> ... could be confused with dense packing
16:54:47 <florian> grid stack is ok
16:54:49 <TabAtkins> (I am strongly against an `-ed` suffix, tho. We just Don't Do That.)
16:54:50 <kbabbitt> ... personal preference is for masonry
16:54:52 <dholbert> (+1 to alisonmaher on packed sounding like "dense", was gonna say the same)
16:54:54 <astearns> ack alisonmaher
16:55:01 <kbabbitt> oriol: wanted to mention personal confusion with dense grid
16:55:07 <kbabbitt> ... for masonry, everyone on the web calls it masonry
16:55:20 <astearns> ack oriol
16:55:22 <rachelandrew> I think of non-masonry options, I prefer grid-pack or grid-stack they are both easy to say clearly and to write, but I prefer masonry.
16:55:30 <kbabbitt> ... maybe the original meaning of this word in English meaning something different, but reality is nowadays everyone calls it masonry
16:55:30 <bkardell> +1 oriol
16:55:38 <kbabbitt> ... if we choose another word we'll confuse everyone
16:55:40 <rachelandrew> +1 oriol
16:55:45 <kbabbitt> ... even apple in blog post title used masonry word
16:55:47 <florian> q+
16:55:49 <lea> q+
16:55:54 <kbabbitt> ... if they used another word in title, people would be confused
16:56:01 <kbabbitt> ... I think not choosing masonry would create lots of confusion
16:56:05 <kbabbitt> ... so I think we should go with masonry
16:56:06 <astearns> ack miriam
16:56:19 <kbabbitt> miriam: could be convinced by that sort of argument, aslo understand arguments against masonry
16:56:22 <kbabbitt> ... don't like the -ed ones
16:56:29 <kbabbitt> .... don't like confusion with pack and dense packing
16:56:30 <dholbert> q+
16:56:33 <lea> q-
16:56:40 <kbabbitt> ... the onese that stand out to me are grid stack and compact grid
16:56:40 <sgill> sgill has joined #css
16:56:42 <astearns> ack florian
16:56:45 <kbabbitt> ... those describe best to me what's happening
16:56:57 <kbabbitt> florian: don't entirely buy the argument based on everyone calling it that
16:57:05 <kbabbitt> ... people who ahven't been doing this yet haven't been calling it anything
16:57:14 <kbabbitt> ... the future hopefully is longer than thet pasty
16:57:26 <kbabbitt> ... number of people who will need to learn is much greater than people who already know
16:57:28 <kbabbitt> s/pasty/past/
16:57:29 <bkardell> that's kind of how language works though
16:57:34 <keithamus>  q+
16:57:47 <astearns> ack dholbert
16:57:48 <kbabbitt> ... we're still relatively early, those who already know masonry by that name isn't good enough for me
16:57:48 <noamr> q+
16:57:56 <kbabbitt> dholbert: not opposed to stack word in general
16:58:07 <kbabbitt> ... grid-stack in that formulation sounds like a single track
16:58:20 <kbabbitt> ... a stacked grid sounds like better description'
16:58:23 <kbabbitt> ... grid-stack sounds like single track with rows within it
16:58:30 <astearns> zakim, close queue
16:58:30 <Zakim> ok, astearns, the speaker queue is closed
16:58:34 <kbabbitt> ... collapsed-grid and staggered-grid are what I would lean towards
16:58:39 <kbabbitt> ... no strong preferences
16:58:43 <astearns> ack keithamus
16:58:50 <kbabbitt> keithamus: not a huge fan of many names, feel very generick
16:58:55 <kbabbitt> ... stack doesn't imply shrinking
16:59:03 <kbabbitt> ... pack is maybe best of options, also maybe compact or dense
16:59:11 <kbabbitt> ... or I wonder if natural is worth considering
16:59:14 <kbabbitt> ... or balanced
16:59:21 <kbabbitt> ... pack is probably my preference out of those
16:59:25 <astearns> ack noamr
16:59:36 <castastrophe> +q
16:59:38 <lea> q?
16:59:39 <kbabbitt> noamr: stack is conflicting with stacking context, i find that extremely confusing
16:59:44 <lea> +1 noamr
16:59:45 <castastrophe> q+
16:59:46 <kbabbitt> ... something for z-index usually
17:00:00 <kbabbitt> ... as a way to move forward, do one poll without masonry, then discuss masonry vs what we come up with
17:00:10 <astearns> ack fantasai
17:00:32 <kbabbitt> fantasai: wanted to point out that noamr suggested a different tack, semi-grid
17:00:41 <kbabbitt> ... which gets at idea that it's grid in one axis not the other
17:00:43 <florian> I'm ok with semi-grid too
17:00:49 <kbabbitt> ... re: grid-stack variation wiould be that it stays separated
17:00:52 <castastrophe> Just wanted to +1 pack because it's evocative of less gridded layouts; grids and stack to me imply strict lines and order
17:00:59 <kbabbitt> .... 2 different variations, grid stacking in one axis vs both
17:01:05 <kbabbitt> ... 2 possibilities to think about
17:01:13 <kbabbitt> astearns: we're out of time and I'm not seeing consensus yet
17:01:28 <kbabbitt> ... like noamr's idea of doing poll for non-masonry values to see if we can arrive at a single non-masonry alternative
17:01:32 <dholbert> (RE "grid-stack" vs" grid stack", I still don't love it; any "this is a stack" implication just sounds like a single tower rather than multiple towers)
17:01:41 <kbabbitt> ... in addition to the poll it would be useful to know if people have objections to particular non-masonry terms
17:01:53 <kbabbitt> ... suggest we take this back to issue, have a poll, and hopefully take this up again soon
17:02:01 <kbabbitt> fantasai: I will poll the options people advocated for
17:02:06 <lea> I suspect `semi-grid` would not make much sense to most people. to most people grid is not a spectrum from something else to grid. If the spectrum is flex to grid, there is `flex-grid`
17:02:24 <kbabbitt> astearns: for those that tried to get on queue but couldn't please leave a comment in issue, IRC comments probably sufficient but I'd like to see more discussion in issue
17:02:28 <dholbert> ("stacked-grid" or similar avoids that issue to my ear at least - it's a "grid that uses stacking", rather than "a grid that is also a single stack")
17:02:31 <kbabbitt> Topic: end
17:03:11 <astearns> zakim, end meeting
17:03:11 <Zakim> As of this point the attendees have been SebastianZ, romain, kizu, lea, bts, ydaniv, dbaron, noamr, kbabbitt, ChrisL, TabAtkins, Kurt, jfkthame, castastrophe, alisonmaher,
17:03:14 <Zakim> ... rachelandrew, bkardell, oriol, djmarland, keithamus, miriam
17:03:14 <Zakim> RRSAgent, please draft minutes v2
17:03:15 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/22-css-minutes.html Zakim
17:03:22 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:03:22 <Zakim> Zakim has left #css
17:03:26 <miriam> oh, it wasn't minuted that I advocated for grid-stack and (my favorite) compact-grid
17:03:35 <dbaron> by the way, fantasai, I made some minor tweaks to https://wiki.csswg.org/planning/cupertino-2026 but I don't think anything too significant
17:04:09 <dbaron> fantasai, astearns, will the January Cupertino F2F continue the pattern of other recent F2Fs in that timezone of running from 8am-4pm?
17:08:40 <miriam> (nm I misread)
17:21:15 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/22-css-minutes.html fantasai
17:36:02 <fantasai> dbaron, let me ask
18:18:39 <Linux_Kerio> Linux_Kerio has joined #css