[css-grid-3] Masonry Switch Syntax

[fantasai]

In #11243 we ended up resolving to:

• Re-use the grid-* properties for templating and explicit placement.
• Adopt the item-flow proposal (in principle) for flow control. See [css-flexbox][css-grid] Unifying grid-auto-flow and flex-flow #11480

With that context, I'm opening this issue to focus on one specific sub-point of the syntax debate: how do we trigger masonry layout?

The three proposals so far are:

• Use a new display value. Adopted but needs name bikeshedding, see below.
• Use display: grid + grid-template-rows/columns: collapse.
• Use display: grid + item-pack: collapse (allowing it to show up in the item-flow shorthand as .e.g. item-flow: row collapse).

Now that item-flow has been adopted, nobody is advocating for the grid-template-rows/columns option. But people wanted some time to absorb the new item-flow situation before deciding. See https://www.w3.org/TR/css-grid-3/#flow-control

New ideas are also welcome.

UPDATE: The CSSWG resolved to use the display property together with a value that includes the word grid. Currently looking for proposals on what that name should be. It could be grid-something, something-grid, or grid something/something grid (two keywords). SEE THIS NAMING POLL.

Names proposed so far include:

• collapsed-grid or grid collapse
• grid-stack or stacked-grid
• grid-pack or packed-grid or grid pack
• compact-grid or compact grid
• grid-masonry or masonry-grid
• grid-flex or flex-grid
• grid single-axis (masonry grid) vs grid dual-axis (normal grid)
• grid stack (masonry grid) vs grid grid (normal grid) -- or likewise with another keyword
• staggered-grid or grid staggered
• uneven-grid
• semi-grid
• lane-grid or grid-lanes
• axial-grid

[nathanchase]

+1 for item-pack: collapse

collapse captures the essence of masonry layouts - allowing elements to collapse into available spaces, rather than adhering to a rigid grid structure.

• dense packing optimizes placement while maintaining row integrity
• collapse optimizes placement by breaking the row constraint entirely

Makes sense to me.

[alisonmaher]

After analyzing all recent inputs on the syntax switch thus far, my opinion remains unchanged that display makes the most sense as the trigger.

Re: display as the trigger

Firstly, let’s start by looking at the definition of a display type. According to css-display-3, a display type “defines...the kind of formatting context it generates, dictating how its descendant boxes are laid out.” In other words, a display type defines the way in which sizing and positioning happens for its children.

In Grid, we place items then size the tracks. Masonry is the opposite and has a very different placement algorithm than Grid. Masonry also introduces differences in track sizing, new rules for dense packing and fit-content, differences in how subgrid works, differences in alignment, etc.

Although there are overlaps between Grid and Masonry, they each size and place items differently, which under the definition of display type, means these are distinct modes. As such, reusing display as the trigger for masonry reuses an existing property for its intended purpose.

Moreover, the long list of differences, including differences in the set of properties that are valid or mean different things in each layout mode leads me to believe we will continue to come across extensions of either that don’t make sense in the other, which would be limiting if grouped under the same display type (such as how repeat(auto-fill, auto) could work in each).

A post on the miragecraft blog summarizes this point quite well - “However if we do discover a use case for a potential masonry feature that is impossible to implement when integrated into the grid, that would be a much bigger problem to deal with.”

And lastly, a post by Keith Grant provides an insight into the teachability of using display:masonry over integrating masonry into grid. “If masonry is a part of grid, the way to teach masonry becomes: 'go learn grid at a deeper level.' Then, upon learning more about grid, the next step becomes: “half of what you just learned about grid does not apply to masonry…. I think it’s far more approachable to teach display: masonry…Then, at the end of that lesson, you can say, 'and the good news is, most of what you just learned applies to grid as well!'"

Re: item-flow as the trigger

Webkit’s most recent blog surrounding using item-flow as the trigger actually explains the need for a new display type (unintentionally) quite well - the blog note that Grid’s “layout mode” is in the form of rows and columns, creating a layout mode of strictly aligned cells. Flexbox’s “layout mode” is that of distinct rows or columns in one axis, and masonry’s “layout mode” being “strict columns and messy rows…while the rows are inconsistent and broken up”.

Per the examples in the blog, masonry’s “layout mode” actually more similarly matches that of Flexbox. What the blogpost calls “messy rows” are not rows at all, and although masonry shares similar track terminology and functionality to grid in one direction, masonry does not create the same kind of “layout mode” where distinct rows/columns are formed into a cell-like format. The way we distinguish different layout modes today is through display.

Furthermore, simplifying the differences between Masonry and Grid to how items flow within a Grid is not painting the full picture. For other kinds of item flow values, the core “layout mode” remains unchanged. In Masonry, switching the item flow of the container not only changes how the items flow, but the container no longer has distinct cells (rows and columns). As such, we need a way to trigger masonry that captures all of these differences.

Re: grid-template-columns/rows: masonry as the trigger

When writing tests, I personally found the syntax of setting masonry on either the template row/column direction to force me to think deeply about what direction I was applying to the stacking axis. A post on River’s Blog summarizes this point well - “using grid-template-columns/grid-template-rows with masonry goes against my intuition. Simply put, to achieve a vertical waterfall flow, you need to use grid-template-rows: masonry, while I instinctively thought it would be grid-template-columns.”

I found that setting masonry-direction to define the stacking axis, and grid-template properties to define the grid direction to be much more self-explanatory, easier to remember, and easier to reason about.

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-3] Masonry Switch Syntax, and agreed to the following:

• RESOLVED: Switch for masonry will be a new display type. Display type must include the word grid in the name. We will open an issue for the exact name.

The full IRC log of that discussion

<kbabbitt> alisonmaher: 3 different switch syntaxes proposed
<kbabbitt> ... the one that triggers based on grid-template-columns/rows masonry
<kbabbitt> fantasai1: we left that one behind
<kbabbitt> ... when we transitioned to item-flow
<kbabbitt> ... because that resolved TAG concern about conflicting setting
<kbabbitt> alisonmaher: so that leaves 2 items
<kbabbitt> ... one to use item-flow: masonry as trigger for masonry
<kbabbitt> ... and keep masonry integrated into display: grid
<fantasai1> s/masonry/collapse/
<fantasai1> [oops, should be the item-flow one]
<TabAtkins> https://webkit.org/blog/17219/item-flow-part-2-next-steps-for-masonry/
<kbabbitt> TabAtkins: [projecting chart from blog post above]
<kbabbitt> fantasai1: review item flow proposal
<kbabbitt> ... idea was a set of properties that control flow of how items are placed
<kbabbitt> ... discussed at last F2F or one before, unified set of properties that would control placement of items across all layout modes
<kbabbitt> ... flex, grid masonry and any new ones we introduce
<kbabbitt> ... would be a replacement for, or shorthand of, flex-flow and grid properties and associated controls
<kbabbitt> ... we packaged these properties under a shorthand called item-flow
<kbabbitt> ... one potential set of subprops would be item-direction, item-wrap, item-pack, item-slack
<kbabbitt> ... that creates this package of properties that control placement, how densely you pack, how you wrapm etc
<kbabbitt> ... introduced new initial values which are automatic to get correct defaults
<kbabbitt> ... gives a unified system for all the different things
<kbabbitt> ... opens up interesting questions such as what does dense packing mean for flex
<kbabbitt> ... what if we introduce a balance keyword
<kbabbitt> ... new options for interesting layout options
<kbabbitt> ... 2 key questions opened up with this approach for masonry
<kbabbitt> ... first, could we use one of these item properties as the switch between grid and masonry\
<kbabbitt> ... proposal was to have item-pack collapse, collapse one of the axes you were placing in
<kbabbitt> ... relationship between masonry and grid is to collapse one of the axes
<kbabbitt> ... alternative to have a separate display type as alisonmaher pointed out
<kbabbitt> ... second question is, what does row and what does column mean for masonry
<kbabbitt> .,.. because for grid and flex, direction you place items is also direction of structure of layout
<kbabbitt> ... when you make row tracks you place in row direction
<kbabbitt> ... but in masonry with row track syouy place in column direction
<kbabbitt> ... difference in placement vs track direction
<kbabbitt> .... so what is the name of property, and what is row vs column
<kbabbitt> ... discussion in webkit article
<kbabbitt> ... that brings back to question of this issue, do we put masonry switch into this system and have it be a variation of display:gryd
<kbabbitt> ... or make it independent display type
<kbabbitt> alisonmaher: reasons for separate display type:
<kbabbitt> ... I mentioned, we should look at definition of display type
<SebastianZ1> q+
<kbabbitt> ... defines kind of formatting context it generates dictating how descendants are laid out
<kbabbitt> ... defines how sizing & positioning happen for children
<kbabbitt> ... grid & masonry define these differently in item placement & track sizing happen in different orders
<TabAtkins> q+
<kbabbitt> ... lots of differences between sizing & placement between the two
<kbabbitt> ... resuing display as trigger reuses existing property for its intended purpose
<kbabbitt> ... we've seen lots of differences in how the two should work, e.g. repeat auto-full auto
<kbabbitt> ... and we're bound to find future cases where something works in one but not other
<kbabbitt> ... keeping them in same display type will limit us in those cases
<kbabbitt> ... there was an article from someone who teaches css
<kbabbitt> ... said display masonry would be easier than teaching both
<kbabbitt> ... would need to first learn grid and then masonry
<kbabbitt> ... vs first learn masonry, then grid where some of what you learned applies
<kbabbitt> ... why item pack collapse doesn't make sense to me is, simplifies difference to flow of itemns
<kbabbitt> ... but when you switch to masonry you're no longer guaranteeing layout with distinct rows and columns
<florian> q?
<kbabbitt> ... if we're saying flow items is different, not painting the whole pictyure
<florian> q+
<kbabbitt> ... what webkit called a different layout mode which is more similar to flex than grid
<kbabbitt> ... we need a switch that captures that in a better way
<kbabbitt> ... other existing item pack properties don't affect layout mode
<kbabbitt> ... just how items flow
<kbabbitt> ... placing this within that property doesn't do these difefrences you're gettin gby switching to masonry justice
<kbabbitt> ... existing property we have for this is displaty
<JoshT> +1
<astearns> ack SebastianZ
<kbabbitt> SebastianZ1: didn't closely follow discussion regarding display value vs integrating into grid
<kbabbitt> ... huge discussion in the issue
<kbabbitt> ... still tend to say it should be a separate display type
<kbabbitt> ... should be switch for turning on masonry
<kbabbitt> ... also comes with some consequences regarding how other things work
<kbabbitt> ... like how you would use item-pack in this proposal
<kbabbitt> ... should be an auto value or something
<kbabbitt> ... when you have display type of masonry and that's the switch packing is normally collapsing
<kbabbitt> ... that opens up more discussion regarding how these item flow subproperties are meant to be specified
<astearns> ack TabAtkins
<kbabbitt> TabAtkins: I agree strongly with arguments alisonmaher made
<kbabbitt> ... differences between masonry and grid are pretty large
<kbabbitt> ... resemble each other in many ways, able to reuse some properties between them
<lea> q?
<kbabbitt> ... substantial delta in how they operate in meaningful and wide ranging ways
<kbabbitt> ... more so than other flags the item properties define
<ydaniv> q+
<kbabbitt> ... they're relatively small tweaks in how we do placement etc
<kbabbitt> ... nothing close to large scale thorough reinterpretation in how layout proceeds in grid vs masonry
<kbabbitt> ... agree that representing this idfference is best done in new display value
<kbabbitt> ... similar to how flex and grid are separate display values even though they can closely resemble each other in many cases
<kbabbitt> ... and be interchangeable to authors sometimes
<astearns> ack florian
<kbabbitt> florian: responding to one subpoiint alisonmaher made
<kbabbitt> ... the fact they will find cases where it wokrs in one mode than other pushes to diff diusplay types
<kbabbitt> ... was pushing to opposite initially
<kbabbitt> ... we might fail to make things work in both cases where we should have done so
<kbabbitt> ... but I think we want to review against both
<kbabbitt> ... no matter how we switch we'll have 2 modes, we'll find cases where one mode can do it other cant'
<kbabbitt> ... doesn't matter how we switch
<kbabbitt> ... if there are casese where we could make it work but don't we're doing a bad job
<kbabbitt> ... we should make it work i both
<kbabbitt> ... orthogonal to question of the switch
<kbabbitt> ... making it work in both cases doesn't lead us in either direction
<kbabbitt> think I'm neutral at this point
<astearns> ack ydaniv
<kbabbitt> s/think/... think/
<kbabbitt> ydaniv: from author point of view, I think in many cases do a lot of trial and error when trying to do layout
<florian> s/I'm neutral at this point/I'm neutral at this point on this sub-argument/
<lea> q+
<kbabbitt> ... they want to do some sort of grid, they try grid and might get what they want
<kbabbitt> ... with masonry sort of more of the same
<kbabbitt> ... if you want masonry, you want a clear switch to flip and eventually tweak everything until you get it right
<kbabbitt> ... good to have something very explicit
<kbabbitt> ... say I want to get masonry
<kbabbitt> ... usually you say you want grid and everything is where you want it
<kbabbitt> ... or go to masonry which is more presentational
<kbabbitt> ... don't care so much about order of content
<astearns> q+
<kbabbitt> ... or controlling content
<kbabbitt> ... more of a ?? flow
<kbabbitt> ... more of a design thing
<florian> q+
<kbabbitt> ... important to have a clear intent or switch
<JoshT> s/??/let it/
<kbabbitt> ... more tending towards display type
<JoshT> +1
<astearns> ack lea
<kbabbitt> lea: more of a general point
<kbabbitt> ... argument for not making a display type is that it combines elements of flex and grid
<kbabbitt> ... some elements of masonry like flex, some like grid
<kbabbitt> ... down the line we may want another display mode with differen tparts of grid & flex
<kbabbitt> ... doesn't scale to keep adding display values authors need to learn
<kbabbitt> ... been exploring idea of folding masonry into grid
<kbabbitt> ... have we explored combining flex with masonry?
<kbabbitt> ... and backporting certain things masonry needs into flex
<kbabbitt> fantasai1: yes
<kbabbitt> ... challenge is with spanning items
<kbabbitt> ... if you span tracks and do flexing it is horrifically complicated
<kbabbitt> ... and unclear what you actually want to do
<kbabbitt> ... a little bit terrifying
<kbabbitt> ... we did explore that direction, it doesn't work
<kbabbitt> TabAtkins: there's significatn similiarities in layout but as a general model masonry is much closer to grid
<kbabbitt> ... would require making flex much more griddy to accommodate it
<astearns> ack astearns
<kbabbitt> astearns: chair hat completely off, been waffling back and forth
<kbabbitt> ... very much on display value side now
<kbabbitt> ... hated the way that we had a whole bunch of masonry this and that properties
<kbabbitt> ... item-flow proposal makes that problem go away
<kbabbitt> ... makes the display type make much more sense
<kbabbitt> ... not liking from an author point of view how switch gets nested so deeply into item-flow longhand
<ydaniv> +1 to astearns
<kbabbitt> ... makes more sense to me conseptually to have it at the top
<astearns> ack florian
<kbabbitt> florian: question and depending on answer a point
<kbabbitt> ... which switch we use, does it make any difference to how subgrid and submasonry work?
<kbabbitt> TabAtkins: it does not
<kbabbitt> fantasai1: it does not
<ntim> q+
<kbabbitt> florian: with that, much of this discussion has been based on what expresses intent, what's more teachable
<kbabbitt> ... no difference in behavior but I think there is one
<kbabbitt> ... in terms of robustness & authors not htinking things through
<kbabbitt> .... authors should, but we should account for cases where they don;t
<kbabbitt> ... if an author creates a masonry and forgets to account for browser that don't support
<kbabbitt> ... fallback is to block layout which doesn't do anything sensible
<kbabbitt> ... through item-flow, fallback is a grid, I think this is close enough where fallback makes sense
<kbabbitt> ... fllback to flow makes sense but it's further away
<TabAtkins> q+
<alisonmaher> q+
<kbabbitt> ... with assumption that grid and masonry are close enough that fallbakc works-ish often enough I prefer that
<lea> q+ fallback, subgrid
<oriol> People could also use `display: grid; display: masonry`
<lea> q- fallback, subgrid
<lea> q+
<kbabbitt> ... if they're sufficiently different that falling back from masonry from grid would fail to make sense most of the time, falling to flow is likely to be more robust
<kbabbitt> astearns: flaw in your argument is that item-flow is unlikely to be supported in browsers that don't support masonry
<kbabbitt> ... so if you want to fallback to grid, defining display:grid and then display:masonry is probably the way to go
<kbabbitt> ... as opposed to trying to rely on whether item-flow longhand is defined
<kbabbitt> alisonmaher: I think probably if an aythor wants masonry they want masonry more than grid
<kbabbitt> ... falling back tyo grid without any thought gives them wrong fallback
<kbabbitt> q+ on fallback
<kbabbitt> ... either way this is a temporary problem
<alisonmaher> q-
<kbabbitt> .,.. don't think that should be main reason for one or other
<astearns> ack ntim
<TabAtkins> Yeah, I think in "falling back" to Grid can *sometimes* make sense, if you're using sufficiently similar item sizes, but in the general case it doesn't (and Block can even be better sometimes, it's a single-column Masonry!)
<kbabbitt> ntim: thinking of author experience, display switch would mean we have to write dispolay:masonry grid -tenplate-rows etc.
<kbabbitt> ... and then item-pack collapse
<kbabbitt> ... 3 different vocabulary terms
<kbabbitt> ... people need to learn
<kbabbitt> alisonmaher: I think we're choosing between display or item-pack, not both
<kbabbitt> astearns: ntim was saying you have to choose masonry direction
<kbabbitt> ntim: if you want masonry in column direction, you have to do item-direction column
<kbabbitt> ... would be item-flow not item-pack
<kbabbitt> ... but on author side they have to learn masonry, grid, item, 3 different terms
<kbabbitt> TabAtkins: we already expect people using grid to start using item-flow as well
<kbabbitt> ntim: if we do display property switch they also have to learn masonry as a word
<kbabbitt> TabAtkins: they have to learn a new word regardless, either masonry on display or collapse on item-pack
<kbabbitt> ... one new word on a property
<kbabbitt> astearns: ntim you do have a point that they need to use grid-template property
<kbabbitt> alisonmaher: in either case
<kbabbitt> TabAtkins: when we last discussed this we were very explicit about choice of using grid-template, not prejudicing on this discussion
<kbabbitt> ntim: wondering if we thought, if we go display switch, could we go display collapse grid
<kbabbitt> ... something to make grid association
<kbabbitt> alisonmaher: argument for display type is masonry isn't a grid, doesn't create grid cells
<kbabbitt> ... creates tracks in one directoin
<SebastianZ1> q+ on display: flex/grid + item-pack: collapse
<astearns> ack fantasai
<kbabbitt> ... could discuss other names for it but not sure we want it grid specifically named
<ydaniv> q+
<kbabbitt> ntim: something we might want to consider anyway
<kbabbitt> ... masonry might be a locale specific word
<kbabbitt> ... in some regions people refer to waterfall layout, or ... needs to be discussed
<kbabbitt> astearns; we have a separate issue for that
<kbabbitt> fantasai1: will make case for why it's a variant of grid
<kbabbitt> ... we coming from an app design perspective think of grids as 2d tracks
<kbabbitt> ... historically in graphic desing gridn was considered 1 dimensional
<kbabbitt> ... we're reusing a lot of these ideas and controls from grid layout
<kbabbitt> .... grid template properties etc.
<kbabbitt> ... and concepts of placement
<kbabbitt> ... what we're cretating here is a single axis grid
<kbabbitt> ... distinction between this layout type and flow layout type
<kbabbitt> ... which has atomic units of item sin 1d grid
<kbabbitt> ... leaving for author this is a grid type layout even though it's only in one axis
<kbabbitt> ... that's one reason we want to see it under one display type is we see it as variation on grid based layout
<kbabbitt> ... florian mentioned subgridding, currently the wa masonry and grid are able to interweave in a way that does not create a new formatting context
<kbabbitt> ... other display types we have create new formattying contexts when you switch
<kbabbitt> ... but grid and masonry can coexist in same formatting context because of subgridding relationship
<kbabbitt> q-
<astearns> q?
<TabAtkins> (i mean, it could be cool to "subgrid" a flexbox...)
<lea> Idea: What if we use a distinct `display` value, with `grid` in the name? E.g. `display: grid-1d` (TBB)
<kbabbitt> ... we believe very strongly taht grid and masonry layouts should be as consistent as possible
<kbabbitt> ... florian is right that whether they're a different dusplay type or some other switch doesn't need to influence our deciusion on how they're onsisitent or not
<lea> +1
<kbabbitt> ... thinking about it as a different display type encourages us to think about them as different modes
<astearns> but with item-flow, we are committing to as much consistency as we can manage between flex & grid
<kbabbitt> ... and to allow for divergences where as thinking of them as a single display type encourages us to make them consistent
<alisonmaher> q+
<kbabbitt> ... not necessarily how we do it but leaning in that direction, we want to push back strongly against the idea they should diverge
<kbabbitt> astearns: we've already commmitted to being as consistent as we can between flex and grid with item-flow
<kbabbitt> ... so I don't know that adding another display type is as dire as you suggested
<kbabbitt> fantasai1: not dire, but a nudge in direction
<alisonmaher> q-
<astearns> ack TabAtkins
<kbabbitt> TabAtkins: originally got on to talk about fallback question
<kbabbitt> ... a masonry falling back to agrid can sometimes make sense if items are reasonably same size
<kbabbitt> ... but not common case for amasonry
<kbabbitt> ... if items are same size could just use grid already
<kbabbitt> ... often divergent sizes, and grid will look just as wrong as anything else
<kbabbitt> ... block layout is like one column masonry
<kbabbitt> fantasai1: with margin collapsing and floats
<kbabbitt> TabAtkins: more generally though we have not ever tried to design fallbacks between layout modes in this way
<kbabbitt> ... I can see somewhat of an argument for this but generally not a precent we want to try to establish in the future
<kbabbitt> .... they differ in significant matters and if you're not aware of those difference or browser support
<kbabbitt> ... you get a page looking wrong regardless of what we fall back to
<kbabbitt> .... people should be aware, and if they aren't nothing we do is going to do m uch for design of the page
<JoshT> +1
<kbabbitt> ... we do often care about fallbacks when it would render content unreadable but that's not the case here
<kbabbitt> ... here it would be broken but not designer's intent regardless of which one we do
<astearns> ack lea
<kbabbitt> lea: many things I went on queue to say have been addressed
<kbabbitt> ... I think grid tends to be slightly better fallback than block
<kbabbitt> ... but agrrr with TabAtkins we don't design for that
<kbabbitt> ... long term it's not going to make much of a difference
<kbabbitt> ... so that should not be a driving factor
<JoshT> s/agrrr/agree/
<kbabbitt> ... that said huge +1 to what fantasai1 said
<kbabbitt> ... that having a distinct display mode will encourage divergence
<kbabbitt> ... worried about addingmore down the linke
<kbabbitt> .... +1 to what fantasai1 said about in graphic design grids may not be 1 dimentions
<kbabbitt> ... so conceptually calling it a grid makes sense
<kbabbitt> ... maybe compromise on something with grid in name?
<kbabbitt> ... grid1d
<kbabbitt> ... make it syntactically obvious that it's a grid of some sort
<kbabbitt> ... not a huge fan of that idea but wanted to throw it out
<kbabbitt> ... generally agreeing with fantasai1
<kizu> `display: masonry-grid`
<kbabbitt> ... if we do end up with separate display mode I hope we can come up with something iother than masonry
<ntim> (I think it also would associate it with the grid-template-rows properties to have grid in the name)
<astearns> +1 to kizu (if we need to qualify the value)
<kbabbitt> .... a bit worried masonry is not firendly to non native speakers
<astearns> ack SebastianZ1
<astearns> ack SebastianZ
<Zakim> SebastianZ, you wanted to comment on display: flex/grid + item-pack: collapse
<kbabbitt> SebastianZ1: two things.
<fantasai1> +1 to everything lea said
<kbabbitt> ... iterating on astearns' pooint about unifying the flow and flex flow
<kbabbitt> ... is there also an issue regarding unifying grid template or generalizing grid template or generalizing?
<kbabbitt> fantasai1: no because it's a grid
<kbabbitt> .,.. might be creating grid in one axis but still a grid
<kbabbitt> ... if we decide to call it masonry and there's no grid in name of display value that's not clear
<kbabbitt> ... but if we call it masonry it will be floating around by itself anyway
<kbabbitt> ... but grid is a concept in graphic design and templating properties create taht concept
<kbabbitt> ... eitehr in css grid layout or masonry
<kbabbitt> ... or something else entirely
<lea> q?
<kbabbitt> fantasai1: I don't think we need an alternate name for these properties
<kbabbitt> SebastianZ1: if we introduce new display value for masonry we should also take into account renaming grid template properties to make them align
<kbabbitt> ... so we don't diverge these two tyhings
<kbabbitt> fantasai1: I don't think there's any need to rename
<kbabbitt> alisonmaher: dependin gon how this goes I might open an issue to consider aliasing
<kbabbitt> SebastianZ1: other point I had, if we introduce a display type for masonry
<kbabbitt> ... what would the item pack collapse do?
<kbabbitt> ... for the other layout types
<kbabbitt> ... it would just be ignored
<kbabbitt> TabAtkins: it would be not a thing in the spec at all
<kbabbitt> florian: if we go with display type, there would be no item-pack collapse
<florian> q+
<astearns> ack ydaniv
<kbabbitt> ydaniv: want to stress again that I agree with lea that divergence is something we want to avoid
<kbabbitt> ... still think it's different intent between grid and masonry
<kbabbitt> ... for layout and design
<kbabbitt> ... thing I found most concerning is, if you just change some value to collapse could change order of content
<lea> everyone agrees that we want to avoid divergence. fantasai1 and lea's point was that a separate display mode *encourages* divergence.
<kbabbitt> ... something very desired inmasonry but not in grid
<noamr> q+
<kbabbitt> ... if this is something we think is acceptable for users to accept, just changing to collapse could chuffle order of content then it's fine
<kbabbitt> TabAtkins: a whole lot of other things will change too
<kbabbitt> ydaniv: if it were just tracks collapsing that's reasonable but things will reorder
<astearns> ack florian
<kbabbitt> florian: leaning on idea from traditional graphic design
<kbabbitt> ... 1d grids are fundamentally more common than 2d
<kbabbitt> ... having it be a subtype of grid keyword might be surprising
<kbabbitt> ... what I might prefer as compromise is dispolay type with grid in it
<kbabbitt> ... these 2 types of grids can subnest, together they're a type of formatting context
<noamr> +1
<kbabbitt> ... and because peeople think of masonry as a grid but a 1d thing
<kbabbitt> ... maybe callin git display 1dgrid or similar
<kbabbitt> ... which puts emphasis on fact that it is a grid and they shouldn't diverge, and they can nest
<fantasai1> grid-collapse? grid-pack? grid-stack?
<kbabbitt> ... maybe that helps with the messsiness without having an obscure name as a nested layout type
<TabAtkins> I don't have a strong naming opinion (but grid-stack sounds okay to me, honestly)
<astearns> ack noamr
<kbabbitt> noamr: what I like about display type is it's a clear distniction
<kbabbitt> ... doesn't matter if it has the word grid in it
<kbabbitt> ... more that devloper has safetlyt and clear disticntion
<kbabbitt> ... there were years of css being, you moved htis button and this other thing moved
<kbabbitt> ... if I can say there's a boundary here
<kbabbitt> ... maybe same name included in both
<kbabbitt> ... gives that security of I know this property isn't going to affect this layout
<kbabbitt> ... should prioritize that before our future selves being consistent
<kbabbitt> ... let's put web devs before us
<kbabbitt> ntim: consistenfcy is part of developer experience
<kbabbitt> astearns: we're at time
<dholbert> I'm partial to fantasai's points earlier, regarding formatting contexts and explaining/justifying why subgrid-interleaving "just works" with submasonry. (And +1 to keeping them as similar as possible, to avoid inadvertently introducing complexity when we do have a subgrid with masonry.)
<kbabbitt> ... what I am hearing is that most of the people are for a separate display type
<kbabbitt> ... but would like to have some accommodation for the fact that masonry and grid are linked
<kbabbitt> ... fantasai1 and lea, would bikeshedding the display value to include grid be enough for you?
<kbabbitt> fantasai1: [reads dholbert's statement in irc]
<lea> q?
<lea> q+
<TabAtkins> (reason why grid-stack sounds ok to me is that we already, with no connection to this, ended up calling the two axises "grid axis" and "stacking axis")
<kbabbitt> astearns: I am convinced by both ydaniv and noamr argments that a separate display type better captures all of the side effects of opting in to masonry
<kbabbitt> lea: if we do use a different display type, does that mean we need to opt into masonry in 2 different ways?
<kbabbitt> ... how do they declare they want a masonry grid taht geos along rows?
<kbabbitt> fantasai1: same as grid that goes along rows
<kbabbitt> astearns: you have a default and can switch it
<TabAtkins> (Here's where we define the two axis names: https://drafts.csswg.org/css-grid-3/#masonry-model)
<kbabbitt> ... compromise I'm trying to get to is use display as switch but have the masonry value for display include grid to note connection
<kbabbitt> alisonmaher: would it make sense to discuss that piece in separate issue?
<kbabbitt> florian: kind of the same thing
<kbabbitt> ... I would consider mysel fin fantasai1 and lea camp
<kbabbitt> ... okay with display type if it has the word grid in it
<kbabbitt> ... if not, Im not sure I agree
<kbabbitt> astearns: we could resolve tentatively on masonry-grid but further bikeshed specific value
<kbabbitt> fantasai1: from irc leading candidate is grid-stack
<kbabbitt> florian: don't know if it's amazing good enough for me to yield
<kbabbitt> lea: setting display grid stack also sets item pack to collapse?
<noamr> stack sounds like it's z
<kbabbitt> florian: not it replaces it
<kbabbitt> [crosstalk]
<dholbert> +1 to noamr
<kbabbitt> SebastianZ: we on't introduce taht if we have display type
<ntim> q+
<kbabbitt> fantasai1: debate is whether we use display as switch or do we use item pack collapse?
<dholbert> (we actually literally use a grid with z-index stacking to implement XUL <stack> in Mozilla. :))
<ydaniv> q+
<kbabbitt> lea: currently we have grid ato flow for regular grid
<astearns> ack lea
<fantasai1> The question was, do we use 'display: masonry' or 'display: grid; item-flow: collapse' for masonry
<kbabbitt> ... that lets you set direction
<kbabbitt> ... what happens if you set display to that value and thten set that to other axise
<kbabbitt> ... you use grid trmplate to define which axis your grid goes along?
<kbabbitt> fantasai1: no that was third option we discarded
<kbabbitt> ... what we could do is have auto value for direction property taht depending on whetehr you set columns or rows
<florian> +1 to either item-flow: collapse or display: grid-stack, -1 to display: [something that doesn't include the word grid]
<kbabbitt> lea: but what if you set 2
<kbabbitt> fantasai1: then you default to waterfall
<kbabbitt> lea: even if you set grid auto flow to the other one?
<kbabbitt> fantasai1: grid auto flow and item flow are same property
<kbabbitt> lea: so if you set g-t-columns and g-t-rows
<kbabbitt> fantasai1: itemflow determines orientation
<kbabbitt> [missed]
<astearns> ack ntim
<dholbert> ("display: grid-[something]" seems somewhat-reasonable to me; it at least helps to explain the magic of how the formatting contexts can interleave despite being different display values)
<kbabbitt> ntim: do we foresee any other possible use cases in masonry for item pack collapse?
<kbabbitt> TabAtkins: currently we have nothing else that could be applied by that word
<kbabbitt> ... 3 display values that use items, flex has nothing that could use collapse
<astearns> ack ydaniv
<kbabbitt> ... would solely be a masonry switch absent future hypothetical layout mode
<kbabbitt> ydaniv: I think it is also safer to start with displayt switch
<kbabbitt> ... then if we figure out, we now see emergin patterns, we know fantasai1 was correct, we can addc ollapse
<kbabbitt> ... then that switch can go back to legacy, w9uld be safer
<kbabbitt> fantasai1: don't think we'll do that, whatever we decide here will be what happens
<kbabbitt> astearns: I think I heard objetions to having switch be in item pack
<kbabbitt> ... so I don't think we can resolve on that
<kbabbitt> ... there are several people who have said that display grid stack would be acceptable
<kbabbitt> ... can we resolve on that as switch?
<kbabbitt> dholbert: I've seen the word stack to mean something completely difefrent in graphical layout
<kbabbitt> ... like browser tabs being switched
<kbabbitt> ... that's what it means in ? and I've seen it in java ui toolkit libraries too
<kbabbitt> fantasai1: stacking in z axis?
<kbabbitt> dholbert: yes, and that could be confusing for people coming from other toolkits
<JoshT> +1 to dholbert
<lea> +1
<kbabbitt> ... word stack would be confusing
<kbabbitt> ntim; stack has association in z axis
<dholbert> `stack` looks like this in some graphical toolkits https://www.ibm.com/docs/en/baw/24.0.x?topic=toolkit-stack
<kbabbitt> astearns: could we resolve in display: masonry-grid?
<JoshT> Yes I'm OK with masonry-grid or a poll
<dholbert> ("stacking-grid" might be better)
<kbabbitt> TabAtkins: can we resolve on a display type with naming poll in 2 weeks?
<kbabbitt> florian: ok with constraint that we include the word grid
<noamr> condensed-grid ?
<kbabbitt> astearns: Proposed resolution: Switch for masonry will be a new display type. Display type must include the word grid in the name. We will open an issue for the exact name.
<JoshT> +1
<florian> +1
<kbabbitt> astearns: objections?
<kbabbitt> +1
<fantasai1> wfm
<diekus> <3 +1
<lea> wfm
<kbabbitt> RESOLVED: Switch for masonry will be a new display type. Display type must include the word grid in the name. We will open an issue for the exact name.
<lea> flex-grid