- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jan 2025 20:05:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Masonry Layout Switch`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Subtopic: Masonry Layout Switch<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/11243<br>
<fantasai> scribenick: fantasai<br>
<fantasai> TabAtkins: Question 3 is how do we actually trigger masonry layout?<br>
<fantasai> TabAtkins: We already resolved to use grid-* for defining template, but that doesn't decide this question<br>
<fantasai> TabAtkins: Options are a) New 'display' value, b) 'item-pack: collapse' as shown earlier c) specialized property 'masonry-something' d) grid-template-row/column: masonry-keyword<br>
<fantasai> TabAtkins: I lean toward 'display: masonry'. It avoids the item-pack question. But anything works here<br>
<iank_> `display: masonry` could also be similar to `table-*` e.g. `display: grid-masonry`<br>
<fantasai> TabAtkins: Now that we've agreed on grid-* properties, I'm fine with doing a grid switch for thise<br>
<florian> q?<br>
<TabAtkins> scribe+<br>
<TabAtkins> florian: when yous aid we can do a display value for now and later activate it thru item-pack<br>
<fantasai> TabAtkins: That wouldn't work. Only if we did a dedicated property.<br>
<astearns> q+<br>
<astearns> ack fantasai<br>
<TabAtkins> (we could do a dedicated proeprty now, and later move it to item pack; or do a `display` keyword, and never put it in item-pack)<br>
<TabAtkins> fantasai: i think we shouldn't do with (d) (grid-template-rows: collapse).<br>
<TabAtkins> fantasai: if you set 'collapse' on both axises it's unclear what that means<br>
<TabAtkins> fantasai: now that we have item-pack that's a beetter place<br>
<TabAtkins> fantasai: i dont' think we should intro a specialized property just for this one thing<br>
<miriam> q+<br>
<TabAtkins> fantasai: if we dont' want to ddig too deep into item-pack for now, we can put it into grid-auto-flow where it lives alongside dense, which is already about packing<br>
<TabAtkins> fantasai: when we figure out how that rolls into item-pack, it would roll up in the same way<br>
<oriol> q+<br>
<florian> q+<br>
<astearns> ack astearns<br>
<fantasai> astearns: Now that we've adopted the grid properties etc, I'm leaning more towards using 'display'<br>
<fantasai> iank_: if we're using grid-prefixed properties, we could do a grid-prefixed display keyword. Like tables have table-<br>
<TabAtkins> iank_: do display:grid-masonry, for example<br>
<astearns> ack miriam<br>
<TabAtkins> miriam: the one i udnerstand the least is item-pack, only briefly saw it in a different convo<br>
<TabAtkins> miriam: not sure if that's something you want to flesh out more<br>
<fantasai> TabAtkins: Under that proposal, if you set `item-pack: collapse` in a grid you're doing masonry.<br>
<fantasai> TabAtkins: If you set only one of grid-template-columns/rows, then we go with the axis you didn't set for the masonry<br>
<fantasai> TabAtkins: if you set both, default to making columns<br>
<TabAtkins> fantasai: you forgot to say that if you set item-track:row, it explicitly gives the masonry direction (regardless of the grid-template-* properties0<br>
<TabAtkins> fantasai: if you *don't* set item-track, the "auto" keyword (initial value) looks at grid-template-* and determines the masonry axises<br>
<emilio> TabAtkins: I think fantasai hit everything I wanted to say<br>
<emilio> miriam: I don't think I have other questions<br>
<emilio> fantasai: can you summarize what you understood?<br>
<emilio> miriam: no<br>
<emilio> ... seems to be a lot going into it<br>
<emilio> ... item-pack seems to be doing dense packing as well as balanced packing and potentially collapsed packing<br>
<iank_> q+<br>
<emilio> ... not sure all three track in my mind but gotta think more about it<br>
<TabAtkins> (miriam just stated my own objection better than i have)<br>
<astearns> ack oriol<br>
<emilio> ... there are various normal/auto interactions that play out with other properties, which I think I mostly followed but couldn't summarize<br>
<emilio> oriol: I don't like using grid-auto-flow<br>
<emilio> ... because it decides how you flow order into the explicit grid or if you want to add implicit rows / columns<br>
<alisonmaher> q+<br>
<emilio> ... here it'd be destroying rows/cols<br>
<emilio> ... don't think it mixes well with what it's doing<br>
<emilio> ... would also be opposed to resolving now about the item pack thing<br>
<emilio> ... these need a lot more fleshing out<br>
<emilio> ... in the future when we have better definitions maybe<br>
<ethanjv> strong +1 to oriol<br>
<emilio> ... if we want to resolve I'd prefer display: masonry or grid-template-{rows,columns}<br>
<astearns> ack florian<br>
<emilio> florian: somewhat similar to oriol / astearns comments<br>
<emilio> ... I was on "use grid all the way"<br>
<emilio> ... prev resolution gave us flexibility<br>
<emilio> ... I agree with oriol that grid-auto-flow feels like a weird fit<br>
<emilio> ... display might be fine, ok also with separate prop, ok with separate prop that we roll into item-pack if we figure out, not ok with grid-auto-flow, not ok with grid-template-{rows,columns}<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to let's get clear on this<br>
<kbabbitt> q+<br>
<emilio> fantasai: wanted to go over the rest of the table<br>
<astearns> ack iank_<br>
<astearns> +1 to item-pack being too new (for now)<br>
<emilio> iank_: similar to oriol, given item-pack, I think I also agree about grid-auto-flow being not-great<br>
<jensimmons0> q+<br>
<astearns> ack alisonmaher<br>
<emilio> alisonmaher: wanted to go back to what is a display type<br>
<emilio> ... spec says it determines how the child boxes are laid out<br>
<astearns> ack kbabbitt<br>
<emilio> ... grid and masonry have different enough layout models that I feel a display keyword (tbd) is probably fine<br>
<florian> q+<br>
<bramus> +1<br>
<emilio> kbabbitt: agree with alisonmaher<br>
<fantasai> if item-pack feels too new, then maybe we need to work on settling it first<br>
<emilio> ... I think a new display type is my favorite. My mental model is that we refactored the two prev proposals into a set of pieces that are reusable<br>
<emilio> ... grid-template... could be renamed to row-tracks/column-tracks or something like that to be clearer<br>
<fantasai> -1 on that, I think authors really think of these as grid lines<br>
<ydaniv> q+<br>
<emilio> ... but they're shipped as-is<br>
<emilio> ... so not super important<br>
<emilio> ... other pieces we have is the item properties, which I really like<br>
<emilio> ... sharing concepts like dense packing<br>
<emilio> ... the other important thing is changing the masonry keyword out of grid-template, so they keep defining tracks<br>
<emilio> ... so it doesn't get mixed up<br>
<emilio> ... a display type defines how the items are arranged so that's my favourite of the proposals here<br>
<astearns> ack jensimmons0<br>
<TabAtkins> i think, too, that "collapse" in item-pack is the odd one out - it really *only* applies to grid, not flexbox (and probably not future display modes)<br>
<TabAtkins> q+<br>
<TabAtkins> it is solely the "make grid into masonry" switch<br>
<emilio> jensimmons0: item-pack or some tbd details, that's pretty much the whole reason to create the whole unified item situation<br>
<emilio> ... to give us a more elegant masonry<br>
<emilio> ... if you're an author what do you write, display: masonry, grid-template, item-flow, gap<br>
<emilio> ... four totally unrelated properties<br>
<emilio> ... our hope was that item-pack or some other variation ...<br>
<emilio> ... one of the early points of masonry was that grid-template: masonry was not ideal<br>
<emilio> ... it also feels that is not a different display type<br>
<astearns> q+<br>
<emilio> ... it's an existing layout mode and we change it<br>
<emilio> ... item-pack is that switch that tells you how you pack the grid items together<br>
<emilio> ... where is the elegance for the author?<br>
<emilio> ... how can it feel a more unified system which is what the TAG asked ofr<br>
<emilio> ... that's the idea behind item-*<br>
<emilio> iank_: I think item-pack is the clunkiest of the item-* properties<br>
<astearns> ack jensimmons0<br>
<astearns> ack jensimmons<br>
<emilio> jensimmons0: maybe item-* needs some more work<br>
<astearns> ack florian<br>
<emilio> florian: as I said I no longer object to this being a display value<br>
<emilio> ... but I do have a preference to put it in item-pack or a separate thing that can be rolled into item-pack<br>
<emilio> ... reasons are (1) interaction with subgri<br>
<emilio> ... weird to talk about subgrid if this is not a grid<br>
<emilio> ... everything as a grid where you tweak the collapsiness of it is better<br>
<emilio> iank_: does that stand if we say display: grid-masonry<br>
<emilio> ?<br>
<emilio> florian: it helps if you put grid in it<br>
<emilio> ... but something: collapse also gets us away from the masonry word which isn't great<br>
<emilio> ... it's also tricky from i18n point of view<br>
<emilio> ... if we can call it something-collapse seems better<br>
<emilio> ... display: collapse doesn't seem sensible<br>
<iank_> q+<br>
<emilio> ... the interaction with subgrid + collapse making more sense makes me thing that a separate prop that can be rolled into item-pack would be better<br>
<astearns> ack ydaniv<br>
<emilio> ... but then again this is a preference not an objection<br>
<emilio> ydaniv: back to jensimmons0 and florian's comments<br>
<emilio> ... I was on the display: masonry team<br>
<emilio> ... but the TAG review made me reconsider<br>
<emilio> ... given the new item props<br>
<emilio> ... I'd like to hear lea's or someone who has been in the TAG, do the new item-* props answer the TAG's concerns?<br>
<emilio> ... is this something that would satisfy the problems you found?<br>
<kizu> I am thinking about `display: masonry-grid` (as a way to have it as a part of display, but still connect to all the grid properties)<br>
<emilio> lea: When the idea was first proposed I think that item-* is the right direction<br>
<emilio> ... haven't considered the details deeply tho<br>
<emilio> ... because we have just heard of them today<br>
<emilio> astearns: given this direction do you think there's an argument that item-* should influence us towards display or item-* switch?<br>
<emilio> lea: that seems like a step backwards<br>
<emilio> florian: which one?<br>
<emilio> lea: having a separate display mode<br>
<emilio> jensimmons0: agreed<br>
<emilio> astearns: so you'd prefer the switch to be in the item-* set?<br>
<emilio> lea: my understanding is that you do it based on the item-* props<br>
<emilio> ... what's the counter argument?<br>
<emilio> iank_: we are not putting it on the template<br>
<emilio> TabAtkins: current options are display, item-*, or new magical property<br>
<dholbert> RE kizu (and I think iank_'s) mention of `masonry-grid` or `grid-masonry`, those potentially get more confusing with `inline-` prefix. (`display: inline-grid-masonry` etc)<br>
<astearns> q?<br>
<astearns> ack TabAtkins<br>
<emilio> TabAtkins: looking back at item-pack it seems collapse is the odd one out<br>
<emilio> ... dense exists for grid<br>
<emilio> ... balance isn't defined anywhere but can be wide<br>
<emilio> ... collapse only applies to grid<br>
<lea> `balance` is certainly useful for both, and is SO HARD to do rn for grid<br>
<emilio> ... only purpose is to switch to masonry mode<br>
<emilio> ... doesn't apply to flex/grid<br>
<kizu> RE dholbert — in theory, we have the two keyword display syntax… `display: inline masonry-grid`<br>
<emilio> ... so it seems we should not use it for this<br>
<dholbert> kizu: right, but in practice people use `display: inline-block` etc<br>
<emilio> ... we should use either a new prop or display<br>
<emilio> ... I lean towards the later<br>
<bramus> s/kizu: right, /kizu, right,<br>
<dholbert> er, sorry, s/kizu:/ RE kizu, .../ (not quoting him for minutes)<br>
<emilio> jensimmons0: feels like there's folks who see items-* pack as the right direction<br>
<emilio> ... and others that prefer display<br>
<emilio> ... I haven't heard why<br>
<emilio> ... have seen impl concerns<br>
<emilio> ... is item gonna work out<br>
<emilio> ... but haven't heard from the pov of 15 years in the future why is display better instead of unified item-* syntax<br>
<astearns> ack astearns<br>
<emilio> astearns: was on the queue for a similar thing<br>
<emilio> ... I wanted to get into the motivations<br>
<emilio> ... we have the prospect of these item props that will have effect on all the layout modes<br>
<emilio> ... and question in my mind is, are grid and masonry sufficiently different for these values<br>
<kizu> dholbert, yes, could be a good way to educate people about the two keywords syntax :)<br>
<emilio> ... that it makes sense to have an external switch that would change how all these props behave<br>
<emilio> ... because there are sufficient differences that this is a different layout type<br>
<emilio> ... or are things like items- consistent between them<br>
<lea> q?<br>
<emilio> ... if that one item property switch has rippling effects to all the other item properties seems wrong to me<br>
<emilio> ... it should be another switch<br>
<emilio> ... but if it just does that other thing, then I'm fine with it being in the item set<br>
<emilio> TabAtkins: re. jensimmons0 I think I have been discussing this in more toward-the-future looking<br>
<emilio> ... in particular collapse not being useful in non-grid layout mode<br>
<emilio> ... I like the other combined props<br>
<miriam> q+<br>
<florian> q+<br>
<emilio> ... and they should be with this generic set<br>
<kbabbitt> +1 to TabAtkins<br>
<emilio> ... but I don't think collapse satisfies that<br>
<astearns> right, that's the other bit I was thinking of. What does a masonry switch mean to flex?<br>
<emilio> ... re astearns, while some of the properties are reusing between grid/masonry, I do thing the item props work differently between masonry and grid<br>
<emilio> ... in the same way they work between grid and flexbox<br>
<emilio> ... the auto-flow of masonry are very different of the behavior on grid<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to suggest we settle the item-* stuff and then come back to this, since it seems some people want to understand better<br>
<emilio> ... so I think that's a good argument for display or an external switch<br>
<lea> It's not just about the future, it's also that this does not seem sufficiently distinct from existing display modes. It seems like a slight tweak over how (wrapped) flexbox works or how grid works (depending on what you see as the switch).<br>
<emilio> fantasai: I think key question might be how do authors think about this?<br>
<lea> Conceptually I'm having trouble thinking how I'd explain it to students as a separate display mode. Even explaining the distinction between grid and flexbox is already somewhat hard to describe, but at least you can piggyback on "one is for 2D alignment, the other not"<br>
<emilio> ... do they prefer seeing masonry as a separate display mode or as a variant of grid layout<br>
<emilio> ... several people have said they want to understand better the item stuff<br>
<astearns> ack iank_<br>
<emilio> ... so might be worth revisiting<br>
<lea> I don't think this is something that authors can evaluate without actually trying it out<br>
<astearns> ack miriam<br>
<bramus> +1 to Lea<br>
<emilio> miriam: I think understanding items-* better would help<br>
<emilio> ... in some way I was trying to think about the cross axis<br>
<emilio> ... so maybe it doesn't belong on the generic items-*<br>
<argyle> q+<br>
<emilio> ... so I lean to either different display (but that's weird because we want grid properties)<br>
<iank_> `display: flow-root`<br>
<iank_> :P<br>
<emilio> ... Not convinced in the hyphenated names<br>
<lea> I think I just realized what gives me pause about a new display type: display types are essentially modes, and modes have established usability issues (mode errors)<br>
<emilio> miriam: I'm thinking of it about how grids handle the cross axis, in my mind<br>
<emilio> ... which leads me towards template-{rows,columns} keyword<br>
<emilio> ... understand the arguments against<br>
<schenney> I agree with framing: How grid packs in the off-axis.<br>
<emilio> ... so maybe this is a new prop?<br>
<TabAtkins> lea, is that a general argument agaisnt display:block and display:flex, for example? Or more specifically about grid and masonry?<br>
<dholbert> iank_, ah right, I forgot we've got that one with a hyphen already<br>
<miriam> that's fair<br>
<emilio> jensimmons: I don't believe there's a mandate for items-* to apply for every layout type for every value<br>
<emilio> ... I don't think we have consensus that e.g. balance could do anything in grid<br>
<lea> TabAtkins: often modes are unavoidable. But it's a good rule of thumb to try and limit them.<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<emilio> ... I don't think we agree that if collapse only applies to grid it doesn't belong on items-*<br>
<miriam> I wasn't thinking of it as a mandate, as much as an awkwardness :)<br>
<astearns> ack florian<br>
<emilio> ... might be interesting to think about how collapse could apply to flexbox<br>
<kbabbitt> I think a lot of the value of the item-* properties is that they do describe concepts that can apply to several display modes. I put them in the same mental bucket as e.g. `gap`<br>
<dholbert> jensimmons, 'collapse' already means something in flexbox, via `visibility:collapse`, which makes this a bit tricky in terms of term-overloading<br>
<emilio> florian: I think we should defer and explore items-* a bit more<br>
<emilio> ... it feels somewhat in between<br>
<emilio> ... in some ways it's a different display mode<br>
<emilio> ... but it's grid-ish<br>
<TabAtkins> (and that "collapse" behavior is definitely completely distinct from what's happening with grid/masonry)<br>
<dholbert> (visibility:collapse creates "struts" in flex, though I recall those not being entirely interoperable)<br>
<emilio> ... kinda separate but only later<br>
<emilio> s/later/partly<br>
<emilio> ... maybe it fits display, maybe items, maybe separate<br>
<miriam> this is `grid-flex` in my heart<br>
<fantasai> `visibility: collapse` collapses a flex item that it's set on<br>
<emilio> ... we've changed a lot of stuff<br>
<emilio> ... not a lot has proved that this is the same thing<br>
<emilio> ... gap applies to a lot of things, doesn't mean that cols is a flex<br>
<astearns> ack argyle<br>
<emilio> ... still this is the more grid like<br>
<emilio> argyle: I've heard lots of things that I didn't know I wanted<br>
<emilio> ... like balancing / sorting<br>
<emilio> ... packery instead of masonry<br>
<emilio> ... if we don't commit so hard to the concept of masonry<br>
<fantasai> s/packery/JS library named packery/<br>
<emilio> ... gap / cols / etc... I think there's a power to find more subtypes<br>
<emilio> ... so I think we can make it better<br>
<emilio> ... masonry++ or somesuch<br>
<emilio> ... the one thing I thought I'd be convinced of<br>
<emilio> ... flexbox has an axis<br>
<emilio> ... grid has more, collapsing an axis feels weird<br>
<emilio> ... so I think of masonry of a different non-flex / grid<br>
<emilio> ... I think it's a good direction we're going towards tho<br>
<lea> q?<br>
<emilio> astearns: agree with florian we need to digest items-* and come back<br>
<emilio> ... I think it's a good way of framing both proposal, but we need to break for lunch<br>
<lea> are the slides available somewhere? Or their content?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11243#issuecomment-2628307500 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 January 2025 20:05:59 UTC