Re: [csswg-drafts] [css-grid-3][masonry] Enabling repeat(auto-fill, auto) (#10915)

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