- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 20:10:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] Enabling repeat(auto-fill, auto)`, and agreed to the following: * `ACTION: TabAtkins to open item size basis issue` * `ACTION: fantasai to open issue to change name` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> fantasai: when we were discussing masonry proposals, one of the points in the display:masonry proposal was that we can have syntax not allowed in grid properties<br> <kbabbitt> ...and use that to do cool new stuff<br> <kbabbitt> ... one of the cool new things advocated for was repeat(auto-fill, auto)<br> <kbabbitt> ... which we don't allow in grid because grid figures out how many tracks exist before figuring out their sizing<br> <kbabbitt> ... but in masonry we have to figure out the track sizing before we can do placement<br> <kbabbitt> ... so we have this rule where we size the tracks as if every auto placed item was placed in the track<br> <kbabbitt> ... and that allows us to resolve the sizes of tracks before doing actual placement<br> <kbabbitt> ... by doing that, it means we can resolve track sizes without knowing which items are placed in them<br> <kbabbitt> ... so we could in theory do track sizing even before we know how many tracks there are<br> <kbabbitt> ... so that would enable repeat(auto-fill, auto)<br> <fantasai> repeat(auto-fill, auto)<br> <kbabbitt> ... which figures out how many tracks you could maybe fit<br> <kbabbitt> ... by doing the sizing as if all items were in this auto track, sizing it, then using resulting size to figure out number of repetitions<br> <kbabbitt> ... this issue is about, should we try to add something like this to grid track sizing in general<br> <kbabbitt> ... and how do we feel about questions around explicit placement<br> <kbabbitt> .. and the fact the auto we use to calculate repeats is not the same as auto we might set the track at<br> <kbabbitt> jensimmons: one question I'd love to hear from rachelandrew or others on<br> <kbabbitt> ... is this really useful to authors?<br> <kbabbitt> ... I don't think it is and can explain why but would like to hear from those who think it is useful<br> <kbabbitt> TabAtkins: I think that it's useful to have by default a masonry ... so long as your elements are reasonably sized by themselves<br> <kbabbitt> ... e.g images with natrual sizes<br> <kbabbitt> ... having default behavior to declare a masonry container be: give me as many columns as I need for these children<br> <kbabbitt> ... seems like most useful default absenty anything else<br> <kbabbitt> ... there are cases where it won't work e.g. if it's all text<br> <kbabbitt> ... in a lot of cases you will, e.g. explicitly sized elements<br> <kbabbitt> ... you can always adjust from there if needed<br> <kbabbitt> ... but it will at least be a decent answer that looks like a masonry right away<br> <kbabbitt> fantasai: we have 2 issues<br> <kbabbitt> ... separate issues<br> <kbabbitt> ... what should initial value be is next issue<br> <kbabbitt> ... this issue is whether we should have this capability at all<br> <jensimmons> q+<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to clarify the issue scope<br> <kbabbitt> ... which is different from inital value<br> <kbabbitt> ... I thnk there are use cases where this would be useful<br> <kbabbitt> TabAtkins: I think this is a useful value because it gives an okay initial result<br> <astearns> q+ to ask what happens when it won’t work<br> <kbabbitt> jensimmons: I do understand what we're talking about, whether it's initial value or not, I question whether it's worth doing<br> <kbabbitt> ... if it's easy to do, won't hurt anything, if it's hard. not worth it<br> <kbabbitt> ... sounds amazing on its face<br> <kbabbitt> ... where you put auto, either intentionally or by defeault<br> <kbabbitt> ... and you don't have to worry about defining track sizes<br> <kbabbitt> ... or this many tracks between these sizes<br> <kbabbitt> ... instead you can automatically get right amount<br> <kbabbitt> ... but when I dug into this, it was complicated enough I couldn't figre it out by myself<br> <kbabbitt> ... fantasai and I wanted to write about it<br> <kbabbitt> ... one of the hardest things I've had to write about, to wrap my head around what auto does<br> <kbabbitt> ... truth is it doesn't do much<br> <fantasai> s/about it/about it, and it took many days/<br> <kbabbitt> ... great that you don't have to worry about track definition<br> <kbabbitt> ... but most of the time, author is still going to have to go in and size all the content<br> <kbabbitt> ... which takes higher skill and takes longer<br> <miriam> q+<br> <kbabbitt> ... more fragile to do that way<br> <kbabbitt> ... does depend on type of content<br> <astearns> ack jensimmons<br> <kbabbitt> ... doesn't work for a paragraph because it will just unfutrl and take 100%of containing block<br> <kbabbitt> ... will work on text that does not wrap<br> <fantasai> Example: https://webkit.org/wp-content/uploads/image7-megamenu-light.png<br> <kbabbitt> ... one of our demos was a mega menu of all menus<br> <kbabbitt> ... as long as no phrases wrap it would automatically make columns<br> <lea> q?<br> <fantasai> s/unfutrl/unfurl/<br> <kbabbitt> ... images are normally bigger than the stuff ? end up on thepage<br> <kbabbitt> ... made smaller with CSS<br> <kbabbitt> ... not common anymore to put natrual size of image on page<br> <kbabbitt> ... often it ends up as a 1x image<br> <kbabbitt> ... will look really bad on modern screern<br> <iank_> fwiw the menu case in the webkit blog doesn't actually work the `max-contrent` in the repeater gets resolved as zero `grid-template-columns: repeat(auto-fill, minmax(max-content, 24ch));`<br> <kbabbitt> ... I think it sounds like this amazing tool but when we looked at the code in depth, we realized it's useful 5% of the time<br> <kbabbitt> ... 95% of the time author will get a mess<br> <kbabbitt> ... and will need to go size all of the content manually<br> <kbabbitt> ... so why? better to just define masonry track<br> <kbabbitt> astearns: what is the failure mode? when it doesn't work, then what?<br> <astearns> ack astearns<br> <Zakim> astearns, you wanted to ask what happens when it won’t work<br> <kbabbitt> TabAtkins: depends what you mean by fail<br> <iank_> q+<br> <kbabbitt> ... if there are e3lements full of text with no reasonable isze, you get 1 track<br> <kbabbitt> astearns: because 1 element takes up all room anyway<br> <kbabbitt> jensimmons: a lot of times you end up with 1 column<br> <kbabbitt> ... but could also have >1 column but width is not what you want<br> <kbabbitt> ... width of column is width of shorter string of text<br> <kbabbitt> ... 2 column s wehre e.g. teaser text unfurls to 1 line in 2 columns<br> <kbabbitt> ... each width of longest string of text inthat column<br> <kbabbitt> ... or columns with images taht arte all different sizes<br> <kbabbitt> ... all at 1x now .look pixelated, look blurry<br> <kbabbitt> ... each column is width of widest image at 1x in taht column<br> <kbabbitt> .. other images in that column could be narrower<br> <kbabbitt> ... file is not big enough to take up whole space<br> <kbabbitt> ... widest one will make width of column, others will be blurry and look weird<br> <astearns> ack miriam<br> <kbabbitt> miriam: have some of same concerns as jensimmons<br> <kbabbitt> ... I almost never use auto when I'm sizing columns in grid<br> <kbabbitt> ... byut often use it when sizing rows<br> <kbabbitt> ... we do allow a row based version of masonry?<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> miriam: that's the place I coul dpotentially see it being useful<br> <kbabbitt> ... in those failure cases how explicit do I have to get to fix it?<br> <kbabbitt> ... I have cards with images that are too big with wrapping text<br> <kbabbitt> ... how explicit do I need to be, just max-width?<br> <kbabbitt> TabAtkins: depends what you're trying to do<br> <kbabbitt> ... might set a number of masonry columns as flexes<br> <kbabbitt> ... might set repeat widtyh<br> <kbabbitt> fantasai: miriam knows how to set up correct tracks, was asking what happens if she uses this feature<br> <kbabbitt> miriam: in order to get some reasonable behavior form auto, if I have images that are big and text that wraps in cards<br> <kbabbitt> ... how explicit do I ned to be on each card to make this useful?<br> <kbabbitt> TabAtkins: should be just max-width<br> <kbabbitt> fantasai: no it won't<br> <kbabbitt> ... typically when you're trying to craete columns<br> <kbabbitt> ... say I want many columns with width based on size of conten<br> <kbabbitt> ... except I want to shirnk content so I set max-wdith 200px<br> <kbabbitt> ... and I have a container that's 700px<br> <kbabbitt> ... then I will say I can fit 3 columns here<br> <kbabbitt> ... so I create 3 columns but then the content is never going to grow to fill...<br> <kbabbitt> ... if I said 3 column sI would difined 700px by 3<br> <kbabbitt> ... the layout I want is 233px columns<br> <kbabbitt> .. cards should be 233px each<br> <kbabbitt> ... ignoring gaps<br> <TabAtkins> (233px is assuming the deffault "stretch" alignment)<br> <kbabbitt> ... but I won't get that because max-width is 200px<br> <kbabbitt> ... so my cards will not grow to fill that extra 33px<br> <kbabbitt> ... won't get the stretychiness you want<br> <lea> I'm not sure I grasp all the details of this issue so feel free to ignore this if not relevant, but being able to delegate the grid definition to grid items (via `min-*`/`max-*`) instead of having to define everything on the grid container is something I have often wished was possible (and a reason folks reach for flexbox even for some grid-like use cases). It sounds like `repeat(auto-fill, auto)` allows exactly that (?)<br> <kbabbitt> jensimmons: there's a drawing of this in the webkit article<br> <TabAtkins> lea, it does (subject to the constraints of doing so, which elika is outlining)<br> <kbabbitt> jensimmons: columns are squishy but images have fixed max size<br> <kbabbitt> ... so you end up with gray space<br> <kbabbitt> ... [as seen in example]<br> <kbabbitt> astearns: how much would miriam need to do?<br> <kbabbitt> fantasai: we figured out something extremely hacky which we would not want to recommend<br> <lea> Thanks TabAtkins! I've also often needed `minmax(auto, 1fr)` or `minmax(1fr, auto)` which never seems to work (though I haven't followed those specs so no idea if that's spec or implementation)<br> <kbabbitt> ... takes advantage of how percentages resolve and don't in different parts of algorithm<br> <kbabbitt> ... weird stuff we could figure out because I know layout algo<br> <kbabbitt> jensimmons: got to a place where explicitly writing track size was way easier<br> <astearns> q?<br> <kbabbitt> fantasai: overall I think what we found is that this auto track repeat idea for cards, images, ...<br> <kbabbitt> ... doesn't really work<br> <kbabbitt> ... at the point you figure out how to make it work, you should have just set track size directly<br> <kbabbitt> ... is useful for this onscreen example<br> <kbabbitt> ... navigation menu<br> <kbabbitt> ... with narrow or wider columns depending on text size<br> <kbabbitt> jensimmons: thi sisn'r right diagram because all column sare same width<br> <kbabbitt> fantasai: this is the right diagram<br> <kbabbitt> jensimmons: (retracts comment)<br> <kbabbitt> jensimmons: all of these columns will be same width as longest phrase of text<br> <kbabbitt> ...a longer phrase will make all columns wider<br> <kbabbitt> miriam: I can see some cases where this might be useful<br> <kbabbitt> ... seems pretty limited<br> <TabAtkins> (i do have a followup, but maybe it can wait until later in the queue)<br> <kbabbitt> .. curious if there's a smarter auto we can do<br> <kbabbitt> ... smarter auto sounds great<br> <ethanjv> +1 to miriam<br> <kbabbitt> ... if there's a way to get ... with the images it's not going to work<br> <kbabbitt> ... don't see a lot of usefulness to it but that gets to next issue<br> <astearns> ack fantasai<br> <TabAtkins> q+<br> <kbabbitt> fantasai: one of the other things to point out here is that for grid we size columns depending on what is placed in them<br> <kbabbitt> ... even for masonry there are rules about explicit placement that impact columns differently<br> <kbabbitt> ... we're assuming in this calc that there's no explicitly placed items<br> <kbabbitt> ... we have to be conservative ie. big enough to accommodate everything<br> <kbabbitt> ... that's a different algo or wider resulting algo than track sizing algo<br> <kbabbitt> .... even if we want to do something like this, another possibility is to give it another keyword<br> <kbabbitt> astearns: "big enough for everything" value<br> <kbabbitt> fantasai: max-content-evenly<br> <ethanjv> can we consider auto to resolve repetitions as if it was sized under min-content?<br> <jensimmons> The article that we were just looking at is here: https://webkit.org/blog/16026/css-masonry-syntax/#:~:text=Extending%20Masonry%20with%20repeat(auto%2Dareas%2C%20auto) (And that link jumps to the right section) if you want to see more details.<br> <astearns> ack iank_<br> <kbabbitt> iank_: the megamenu demo doesn't actually work as expected<br> <kbabbitt> ... when it's resolving auto repeaters it treats max-content as 0<br> <kbabbitt> ... so you get column sof e.g 24ch<br> <kbabbitt> ... it just so happens that content doesn't exceed 24ch<br> <kbabbitt> ... but if a different language did exceed it, you would get overflow<br> <bkardell> s/column sof /columns of<br> <kbabbitt> ... which isn't desirable<br> <kbabbitt> ... so you can't carefully construct your grid-template-columns to satisfy that case<br> <kbabbitt> ... I think miriam, on your case<br> <kbabbitt> ... adding max-wdith on images probably isn't the right thing<br> <kbabbitt> ... what you want is max-width on content wrapper<br> <kbabbitt> ... there are a lot of masonry demos out there with e.g. 600px content 3 columns<br> <kbabbitt> ... disagree it isn't useful for that case<br> <miriam> right, justify-content helps with the results<br> <kbabbitt> ... would be sad to drop this feature, think a lot of devs would reach for this initially<br> <TabAtkins> rows was mirian's point fwiw<br> <kbabbitt> ... to TabAtkins' point for rows this is very useful<br> <astearns> q?<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: the images leaving leftover spae example<br> <kbabbitt> ... does show that if you are stretching columns which happens by default<br> <astearns> s/spae/space/<br> <kbabbitt> ... and still expecting content to fully fill them you may not get ideal result<br> <kbabbitt> ... but if you set max-width 200px and expect 200 to be max width<br> <kizu> q+<br> <kbabbitt> ... and column sare wider than that<br> <kbabbitt> ... still fine because you use alignment to move columns around<br> <kbabbitt> ... or center in colunms or whatever<br> <kbabbitt> ... and if that is not what you want you still want things to be able to grow more than 20ppx<br> <kbabbitt> ..just means you want to be using track sizing at that point<br> <kbabbitt> ... nothing wrong with that but based on content you have, lea pointed in chat that that is useful and apparently causes people to reach for flex intead of grid<br> <kbabbitt> ... even though grid would be better, would be unfortunate for masonry not to address this<br> <kbabbitt> ... finally the initial value if we don't have this is "none' tracks<br> <kbabbitt> ... which generates 1 implicit track<br> <kbabbitt> ... which is almost never what you want<br> <kbabbitt> ... degenerate case<br> <astearns> ack kizu<br> <kbabbitt> kizu: I agree that for row direction it can be useful<br> <kbabbitt> ... not as much in column direction<br> <kbabbitt> ... could have text things that don't fully grow<br> <kbabbitt> ... unstable in column direction, fragile<br> <kbabbitt> .... however I was thinking about this for images<br> <kbabbitt> ... this is something where we might want something similar to flex-basis<br> <kbabbitt> ... some width that defines this that you're allowed to ?><br> <kbabbitt> ... for example if we have 4 inputs right now, they have some magic built in<br> <kbabbitt> ... they have some kind of basis width which is not phrased any other way in css<br> <kbabbitt> ... maybe this is something that could be more general<br> <kbabbitt> ... another intrinsic dimension of an element we could define<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to respond to Tab's example<br> <kbabbitt> .. could be used here and some other places<br> <kbabbitt> fantasai: re: TabAtkins - while yes you could distribute space with alignment properties<br> <kbabbitt> .. very unusual to want to do that<br> <kbabbitt> ... typically want to dsitribute into content itself<br> <kbabbitt> ... so in terms of is this useful? yes<br> <kbabbitt> ... I think there are cases you might want it<br> <iank_> How "mega-menu" renders with a large string. https://usercontent.irccloud-cdn.com/file/gJAPFlqG/Screenshot%202025-04-02%20at%2012.48.21%E2%80%AFPM.png<br> <kbabbitt> ... should it be initial value? no<br> <kbabbitt> ... while you get a masonry layout immediately, the direction you need to tweak things in, it guides you in the wrong idrection<br> <kbabbitt> .. encourages you to tweak item sizing but that's not going to get you where you want<br> <kbabbitt> ... by using `none` we make it obious that track sizing will get you to where you want to go<br> <miriam> Unusual to justify items, but not unusual to justify content (in my experience) which also gets you there<br> <kbabbitt> TabAtkins: don't know I agree it guides you to using sizes<br> <kbabbitt> ... don't think it guides you either way<br> <fantasai> +1 to kizu<br> <kbabbitt> ... track sizing and item sizing are not used yet<br> <kbabbitt> ... either is available to you<br> <iank_> you could make the argument that the normal-value for justify-content to be center<br> <kbabbitt> ... container sizing might be what you reach for first<br> <kbabbitt> ... it can go either way and either is potentially doable<br> <kbabbitt> ... but 1 masonry track for default display is never what you want<br> <jensimmons> q?<br> <kbabbitt> ... whereas auto may be what you want<br> <kbabbitt> ... and dependoing on content often what you want<br> <astearns> ack lea<br> <miriam> q+<br> <kbabbitt> lea: I definitely have stumbled many times on wanting to set layout constraints on grid items<br> <kbabbitt> ... also on flex. settin gon flex items<br> <kbabbitt> ... don't have to make assumptions about children structure<br> <kbabbitt> ... hide contents and set constratins on items to be sized<br> <kbabbitt> ..; which often feels more natural<br> <kbabbitt> ... don't have an opinoin on whether it should be default though TabAtkins's argument seems convincing<br> <TabAtkins> (kizu's point about the need for a flex-basis analog is compelling to me)<br> <astearns> ack miriam<br> <kbabbitt> miriam: think I'm coming artound to utility of this even if limited<br> <kbabbitt> ... as a default<br> <kbabbitt> ... but still interested onpushing on what kizu was saying<br> <kbabbitt> ... and what lea was getting aty with grid<br> <ethanjv> q+<br> <kbabbitt> ... can we improve auto somewhat?<br> <kbabbitt> ... as a basis for items<br> <kbabbitt> ... so we have a target to aim for without using a min or max that will be a final constraint<br> <iank_> q+<br> <kbabbitt> ... fantasai might be right that it's unuitual to use justify-utems to get rid of space<br> <jensimmons> q+<br> <kbabbitt> ... but it's common to use justify-content<br> <astearns> ack ethanjv<br> <TabAtkins> (a 'justify-content:center' to put the extra space on the outside, for isntance)<br> <kbabbitt> ethanjv: following on what miriam said<br> <kbabbitt> .. worth exploring that auto behavior can be improved<br> <kbabbitt> ... cirrently wackiness of items using max width and ? as acombination to expand to columns<br> <kbabbitt> .. could be mitigated by using auto behavior to ???<br> <kbabbitt> ... in the case the webkit blog post mentioned<br> <kbabbitt> ... wackiness because specified max width but want stratch behavior<br> <kbabbitt> ... could explore min-width to auto size content<br> <kbabbitt> ... explore in dfferent auto behavior<br> <kbabbitt> s/min-width/min-content/<br> <astearns> s/min-width/min-content/<br> <astearns> ack iank_<br> <kbabbitt> iank_: posted a screenshot of how safari renders the menu case with a long string<br> <kbabbitt> ... you get content that's ? pretty quickly<br> <kbabbitt> ... this is particularly bad fro i18n<br> <kbabbitt> ... esp if people want to do that type of repeater<br> <kbabbitt> ... you could also argue that normal value for justify-content is center<br> <kbabbitt> ... if this is the default<br> <kbabbitt> ... think that will match a lot of cases where people want this<br> <TabAtkins> that's an interesting idea<br> <astearns> ack jensimmons<br> <kizu> (found a CodePen that demonstrates the inputs magic that I mentioned for reference: https://codepen.io/kizu/pen/dPbQNyW)<br> <TabAtkins> (normal -> center in masonry)<br> <kbabbitt> jensimmons: would be interesting to find out how hard to implement<br> <kbabbitt> ... if not hard, let's do it and see what happens<br> <kbabbitt> .. sometimes we're surprised either way<br> <kbabbitt> ... if it is hard don't know<br> <kbabbitt> ... have not gone in depth thinking things in row direction<br> <kbabbitt> ... don't want to confidently state what I think about that<br> <kbabbitt> ... would ask that ... strongly held opinoins stated in this call<br> <kbabbitt> ... if you really want to understand this, please read the article we wrote<br> <kbabbitt> ... sit down with papere & notebook and thinkg through the algo and how it turns out<br> <kbabbitt> ... still don't see where things fall in column direction except very few use cases<br> <TabAtkins> q+<br> <kbabbitt> ... was surprised ,the more we dug in the worse it got<br> <astearns> ack fantasai<br> <iank_> q+<br> <kbabbitt> fantasai: one thing to point out is, the wy we calculate repetition is going to prefer items that may or may not end up in any of these ? tracks<br> <kbabbitt> ... have to calculate number of repeats before we do any placement<br> <kbabbitt> ... have to place explicitly placed items first<br> <kbabbitt> ... if you have a lot of wide items in explicit track not part of repeat<br> <kbabbitt> ... and narrow items in repeat<br> <kbabbitt> ... algo will still have to size all of those items<br> <kbabbitt> .. doesn't know where explicit items go until it resolves repeat number<br> <kbabbitt> ... going to create somewhat surprising behavior<br> <kbabbitt> .. wondering if we should give that behavior a different keyword<br> <kbabbitt> ... to explain where this sizing goes against items regardless of where placed<br> <kbabbitt> ... would also resolve point iank_ brought uyp<br> <kbabbitt> ... where if you put this in a minmax right now<br> <kbabbitt> ... repetition algo takes a fixed value to calculate the repeat and sizing<br> <kbabbitt> ... and if you don't have an explicit value that's currently not valid<br> <kbabbitt> ... we'd be making it valid, the ? might get weird if we don't have a keyword<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: directly off that, wanted to make sure it was clear<br> <kbabbitt> ... ignoring initial value question, behgavior of any auto keyword when given ? as track size<br> <kbabbitt> ... illegal in grid because we don't know what goes where<br> <kbabbitt> ... propose to allow in masonry because we layou items as we create callins<br> <kbabbitt> s/callins/columns/<br> <kbabbitt> ...need to be more careful since algo is pretend everything is auto placed<br> <kbabbitt> ... and we chop spanners up into pieces<br> <kbabbitt> ... but this is the behavior for all intrinsic sizes<br> <kbabbitt> .. so if you repeat auto fit min content<br> <kbabbitt> ... you get same behavior except using min sizes<br> <kbabbitt> ... if we decide we don't want to mislead people into thinking this is the sameas explicit auto size tyracks<br> <kbabbitt> ... we'd want to do that for all auto size keywords<br> <kbabbitt> ... and ban them in general in auto repeat functions<br> <kbabbitt> fantasai: want to bring back the example iank_ put earlier<br> <fantasai> repeat(auto-fill, minmax(auto, 24ch))<br> <kbabbitt> ... that's currently valid<br> <kbabbitt> ... adnw euse 24ch to resolve number of repeats<br> <kbabbitt> .. the auto that's there gets resiolved after placement in normal way<br> <kbabbitt> ... based on content in that track<br> <kbabbitt> .. keyworkd we're proposing to add here has different behjavior<br> <kbabbitt> ... it's weird that taking out the max and putting auto back is going to get you something fundamentally different<br> <kbabbitt> ... that's why I suggest different keyword, it will resolve differently<br> <kbabbitt> TabAtkins: comfortable with that<br> <kbabbitt> .. would like some kind of auto size auto repetition<br> <kbabbitt> ... don't have a strong opinion on how<br> <kbabbitt> ... if that's giving bad results more comfortable with abandoning<br> <kbabbitt> ... want some way to say "just do the thing"<br> <kbabbitt> ...partially for initial value but also think it's useful explicitly as well<br> <astearns> ack iank_<br> <kbabbitt> iank_: re implementability - don't think it's particularly difficult<br> <kbabbitt> ...esp with grouping of masonry items<br> <TabAtkins> s/if that's giving/if using normal intrinsic sizes is giving/<br> <kbabbitt> ... within context of masonry it's not difficult<br> <kbabbitt> ... doesn't work in grid for good reasons<br> <ethanjv> +1<br> <kbabbitt> ... so it's disjoint there but relatively straightforward in masonry context<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: another reason why it's better not to make this initial value<br> <kbabbitt> ... and push authors to explicit track sizing<br> <kbabbitt> ... it's a little more expensive because you have to scan items up front<br> <kbabbitt> .. which yuou don't have to do other2wise<br> <iank_> q+<br> <kbabbitt> .... other thing to say is if we're adding this, it's not going to be part of grid-template-*<br> <kbabbitt> ... need to give it a meaning in grid as well as masonry<br> <TabAtkins> `repeat(auto-fill, basis)`, with `masonry-basis: <'width'>` as a new property you can optionally set<br> <kbabbitt> ... a bunch of weird things that can happen if author over constrains in both axes<br> <astearns> s/it's not going/it’s going/<br> <kbabbitt> ... if they don't this can give a useful behavior even in grid<br> <kizu> Thinking about a `repeat(sqrt(sibling-count()), 1fr)` default<br> <astearns> ack iank_<br> <TabAtkins> kizu: I mean.........<br> <kbabbitt> iank_: I would somewhat disagree that its more expensive<br> <kbabbitt> ... often as soon as you have anything which is going to expect a min auto size or auto track or anything like that you need to group items<br> <kbabbitt> ... so I don't think it's actually in common case more expensive<br> <kbabbitt> ... basically with masonry we assume everything fits in every column<br> <kbabbitt> ... as soon as you have one column thats ?<br> <kbabbitt> ... you need to group everything into a group<br> <kbabbitt> ... antything except fixed width tracks you need this anyway<br> <miriam> @kizu I think `1fr` would need to be `minmax(0, 1fr)`<br> <kbabbitt> astearns: hearing a range of opinions between this can be useful in some cases to this isn't entirely un-useful<br> <kbabbitt> ... maybe the name needs to change?<br> <kbabbitt> ... maybe we need an item size basis that works in all of these?<br> <kbabbitt> ... things we need to follow up on<br> <kbabbitt> ... not sure we're going yo get farther on this today<br> <kbabbitt> ... people have homework to go through blog post, work out their own examples<br> <kbabbitt> ... counter blog posts would be welcome<br> <kbabbitt> ... should we move on to initial value?<br> <kbabbitt> fantasai: let's give it a try<br> <kbabbitt> astearns: do you have an alternate in mind?><br> <kbabbitt> fantasai: keep current one<br> <kbabbitt> astearns: let's close this issue for now<br> <kbabbitt> ACTION: TabAtkins to open item size basis issue<br> <kbabbitt> ACTION: fantasai to open issue to change name<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10915#issuecomment-2773613362 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 20:10:40 UTC