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