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