- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 09:10:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] Initial value of track listing for masonry grid axis`, and agreed to the following: * ``RESOLVED: Initial track listing for masonry is `none`, same as grid`` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> fantasai1: I'll try to explain how this works<br> <kbabbitt> ... we've been discussing this minmax auto auto stuff [points to whitetboard]<br> <kbabbitt> ... current idea of how that works in masonry is treat every item as appearing in every track<br> <kbabbitt> ... if spanning track dividie it by span<br> <kbabbitt> ... this is a heuristic because items could be placed in certain tracks<br> <kbabbitt> astearns: looking at previous discussion, we decided to defer until we decide on masonry switch<br> <kbabbitt> fantasai1: it will feed in<br> <kbabbitt> ... so there are various aspects wehre this is a heuristic<br> <kbabbitt> ... idea is pretend item is in every track and get a count out of that<br> <kbabbitt> ... having had a count we size all items, place explicitly placeditems, then size all tracks<br> <kbabbitt> ... then do masonry layout or grid layout<br> <kbabbitt> ... so the question here is, should this behavior be the initial value of track listing for masonry layout<br> <kbabbitt> ... or should we, consistent with grid, have a value of there are no tracks and you have at least 1 since it's implicitly created<br> <kbabbitt> ... argument for doing the 1 is that it's consistent with grid<br> <kbabbitt> ... and it also makes it clear you should go set some track sizes<br> <kbabbitt> ... and declare track listing if you want control over how this works<br> <kbabbitt> .... argument for making it initial track listing is, you switched into masonry, make it look like masonry<br> <kbabbitt> ... but whether it looks like masonry will depend on content<br> <kbabbitt> ... if you have an item with same max width as container, still only get 1 column<br> <kbabbitt> alisonmaher: key point I want to call out, even though you might only get 1 column, no worse than current default<br> <kbabbitt> ... in some cases you'll get a more masonry like layout, some you'll get same as grid<br> <kbabbitt> ... but if we can provide a default that might work better for masonry, I don't see a reason why not<br> <kbabbitt> ... this seems like a more valuable default<br> <kbabbitt> fantasai1: our argument is 1. consistency with grid<br> <kbabbitt> ... 2. we went down the path of how it would play out with real content<br> <kbabbitt> ... seemed like there are 2 problems<br> <kbabbitt> ... if you start with multiple tracks based on size of items, then you try to control tracks by controlling size of items<br> <kbabbitt> ... seems natural coming from flexbox but you don't have as much power as with track listings<br> <kbabbitt> ... so it leads in wrong direction, away from track listings<br> <kbabbitt> ... ways you can get behavior for common patterns of content is convoluted<br> <kbabbitt> ... it becomes a way to lead people down the wrong path, they get frustrated<br> <kbabbitt> ... there are some markup patterns where this is, great, it looks like masonry, and I'll max-content it and get something reasonable<br> <kbabbitt> .... but several things play out<br> <kbabbitt> ... what is size of trackks, what do they grow to, how do you distribute extra space<br> <kbabbitt> ... you probably won't get what you want<br> <kbabbitt> ... I have some text content, I picked max size for this phrase, it looks gregat<br> <kbabbitt> ... what if I want it slightly less so I set max size slightly less<br> <kbabbitt> ... that sets width of columns, but extra space stretched into columns can't get used<br> <kbabbitt> ... another example. you have set of images and try to set stuff on them<br> <kbabbitt> ... we went deep on this in one blog post, how authors get columns min of X px and image fills remainder of entire column<br> <kbabbitt> ... becayuse of weird rules for % sizng there's a way to do it but not at all obviouys<br> <kbabbitt> ... can walk down these examples but our conclusion was that for most common patterns, it's going to be either confusing or impossible to get sizing behavior you want<br> <kbabbitt> ... encouraging poeople to explore column sizes by controlling item sizes is not a good direction to lead people<br> <kbabbitt> ... better to direct them toward track sizing<br> <kbabbitt> alisonmaher: had a hard time following examples, but I think no matter what we set default to, authors won't want to chnge it<br> <kbabbitt> fantasai1: authors want to change for sure<br> <kbabbitt> ... if you start with columns based on size of items, we hint to authors that controlling item size controls column sizes<br> <kbabbitt> ... this is a dead end, not how you get intuitive, powerful sizing in masonry<br> <kbabbitt> .... but we've already led them down this pathway<br> <kbabbitt> ... when we start with something where, you're not getting enough tracks, I need more tracks...<br> <kbabbitt> ... yes initial layout is not as useful but you don't take the aythor down this path of bad times<br> <kbabbitt> astearns: comments?<br> <kbabbitt> TabAtkins: don't have a super strong opinion either way<br> <kbabbitt> ... I think exploring as a separate issue I raised somewhere, exploring another way to make intrinsic sizing more intuitive so you can control it on a per item basis is a good idea<br> <kbabbitt> ... suggestion for masonry property that does just that<br> <kbabbitt> ... that's a separate issue<br> <kbabbitt> ... a little unfortunate if things are all fixed size and do not fill out into masonry space<br> <kbabbitt> ... in that case you'd write what defayult is here but I don't care super strongly here<br> <kbabbitt> astearns: anyone want to argue for a better default?<br> <kbabbitt> ... as opposed to requiring authors to specify track sizes to get an actual masonry layout?<br> <kbabbitt> ... don't know that I'm convinced that having a better default would lead people down the garden path of resizing elements to get the layout they want<br> <kbabbitt> ... but don't have a strong opinion<br> <kbabbitt> fantasai1: our conclusion was that overwhelming majority of use cases doesn't find this useful<br> <kbabbitt> ... looks cool looks like a masonry but not what you want<br> <kbabbitt> ... in most cases auto auto auto is not what people who use masonry want<br> <fantasai1> s/but not/but ultimately not/<br> <kbabbitt> astearns: objections to having a dumb default for masonry?<br> <kbabbitt> TabAtkins: Keep current definition, which is `none`<br> <kbabbitt> fantasai1: Initial track listing is `none`, same as grid<br> <kbabbitt> astearns: objections?<br> <kbabbitt> RESOLVED: Initial track listing for masonry is `none`, same as 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/10869#issuecomment-3199910023 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 09:10:59 UTC