- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 03 Dec 2025 16:41:06 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][Masonry] repeat(auto-fill) and minmax()`, and agreed to the following: * `RESOLVED: Keep consistency between grid and grid-lanes, work on a solution for both layout systems` <details><summary>The full IRC log of that discussion</summary> <Kurt> fantasai: there are several pieces to this issue<br> <Kurt> fantasai: repeat:auto fill and minmax with only intrinsic sizes, new scenario so options are open<br> <Kurt> fantasai: open issue of what to do with existing syntax when you mix a definite size and an indefinite size<br> <Kurt> fantasai: in grid, whne you calculate how many tracks, you need to use a size, and we say to use a definite size, min or max and ignore auto<br> <Kurt> fantasai: when you actually resolve tracks, you use the size as normal. Tab is saying in grid-lanes, instead resolve intrinsic size to a heuristic value to what it probably what it would be, minmax the minmax, and get resulting size<br> <TabAtkins> q+<br> <astearns> ack TabAtkins<br> <Kurt> fantasai: I think Webkit has been arguing for consistency, Miriam is arguing that the existing behavior is useful<br> <Kurt> TabAtkins: in masonry, we resolve intrinsic sizes, somewhat heuristic, but we use that size in various scenarios<br> <TabAtkins> i'm back in<br> <Kurt> Miriam: In the specific case of an intrinsic size and an explicit size, I do think it's useful for the explicit size to be used for grid-tracks because it's knowable. I don't like how grid does this when grid takes priority when they're both useful. I don't think it's very useful. I think auto sizing is not used in grid much because it tends to<br> <Kurt> blow out the tracks.<br> <lea> +1 to miriam, I've personally as an author have found the current behavior incredibly hard to reason about or predict. I still don't fully understand it.<br> <lea> (But diverging from it for masonry seems even worse — ideally we should fix it for both with a different syntax)<br> <Kurt> Miriam: only used in row sizing, not in column sizing. It's used to let the column go somewhere after you've given a size in the inline dimension, then you let the content flow and grow in the block dimension, which is already what grid lanes do. I think you'll want to give it an explicit size, I don't think auto sizing is useful.<br> <Kurt> TabAtkins: Argument for consistency both ways - we resolve and use intrinsic sizes in masonry, if you say a track is max-content, we have an answer based on the sizes of things<br> <Kurt> TabAtkins: when you switch from a single value to minmax, if you're using fixed values, we always use the max value. It's not very useful but what we do right now.<br> <Kurt> TabAtkins: If you start with 100px and switch to minmax(100, 200), we always use the larger one<br> <Kurt> TabAtkins: Behavior should be the same in masonry when auto size keywords have a resolvable value<br> <Kurt> TabAtkins: If you start with 100px and switch to minmax(100, auto) we always use the larger one<br> <RRSAgent> logging to https://www.w3.org/2025/12/03-css-irc<br> <Kurt> TabAtkins: The only reason grid has different behavior for putting intrinsic in minmax is that there's no way to resolve it for repetition purposes<br> <Kurt> TabAtkins: so it does the only thing it can, using the fixed value<br> <miriam> q+<br> <Kurt> TabAtkins: not a desirable behavior, it's purely the only option, so we break consistency<br> <Kurt> TabAtkins: In masonry that's no longer needed, we can do consistent behavior - double intrinsic, double fixed, etc, always the larger of the two values<br> <Kurt> TabAtkins: Agree with Miriam, not the most important thing<br> <Kurt> TabAtkins: Good argument for consistency on this side<br> <astearns> ack fantasai<br> <lea> q?<br> <lea> q+<br> <Kurt> fantasai: Track sizing and repetition is fairly complicated, authors have to learn how it works and what it's used for. Having the behavior differ subtly for the exact syntax between masonry and grid is going to cause confusion for authors switching between masonry and grid<br> <astearns> q+<br> <Kurt> fantasai: In terms of whats possible in masonry vs grid, TabAtkins point about intrinsic repetitions in masonry but we can't in grid, but we use the same property. We would like to see a way for intrinsic repetitions to work in grid. If that happens, masonry and grid could be the same behaviors.<br> <astearns> ack miriam<br> <Kurt> Miriam: I agree with Tab there's a consistency argument either way. Is larger-always-wins useful, why is that the one we want if there's a consistency argument either way?<br> <Kurt> TabAkins: Because I think it's very strange to have a case where you start with max-content columns and realize some items are too small, you put a min on that column minmax(50, max-content), and suddenly all columns are 50px, ignoring max-content, drastic change<br> <Kurt> Miriam: It's not ignored, it's on the high end<br> <lea> q-<br> <lea> q+<br> <Kurt> TabAtkins: If you use the high end max-content, 1000px, we use 1000px. May not be useful but it is consistent with masonry and grid in other cases. Unless we redefine entirely behavior, that shouldn't be a consideration. Thinking about the reverse case, which can't be done in grid.<br> <Kurt> TabAtkins: Any complaints that someone might have about minmax(auto, 1000) are the same complaints they will have with double-fixed in masonry and in grid. It's already a behavior shared in all other scenarios, thus not what we're trying to resolve right now. One case is where putting a small min, which dramatically changes behavior in a bad way,<br> <Kurt> just because we want a consistency in grid, which is an error case, but we just have fallback.<br> <Kurt> Fantasai: Is that an error case?<br> <Kurt> TabAtkins: If you put a mixed intrinsic and fixed size in a repeater, because you cannot determine intrinsic size. We cannot use it to estimate track size.<br> <Kurt> Fantasai: I don't think that's an error case, it's just the behavior, it's useful<br> <Kurt> TabAtkins: The example Miriam gave?<br> <lea> q-<br> <bradk> [@kurt, Zoom has pretty good automatic transcription. Looking at that might help with manual transcription if you get behind]<br> <Kurt> TabAtkins: In those cases, it doesn't seem like the intrinsic keyword is a meaningful limit - the repetitions you get are unlikely to run into the intrinsic keyword max - they want a fixed repetition, but there's a little leftover space, and that needs to expand out to fill the repeated columns, but that doesn't need any particular content<br> <Kurt> behavior. You could just as easily write that with an fr value instead of an intrinsic keyword and get the same layout. That would work the same in grid and masonry - fixed and flex instead of fixed and intrinsic.<br> <lea> q+<br> <astearns> ack astearns<br> <Kurt> astearns: I'm sympathetic to fantasai's argument to make it the same in grid and grid lanes and allow for better handling in both for these keywords, but wouldn't that likely require adding something to syntax to say "here we found a way to use intrinsic sizes, but because of backwards compat, you need this new functionality"<br> <fantasai> minmax(100px, 200px) minmax(100px, auto) minmax(auto, 200px) minmax(auto, auto)<br> <TabAtkins> (I suspect Kurt might be behind...)<br> <Kurt> fantasai: we have these 4 patterns - the first 3 are valid and grid and are being used. The 4th is new in grid level 3. Current proposal is use heuristic for auto and use bigger size. We argue the 4th case should do the same heuristic and not just resolve to 1, which is what has been proposed. For consistency and for usefulness in grid, so make it<br> <Kurt> available in both. Existing syntaxes can't change in grid, can be different in masonry, but would be inconsistent. Already complicated, so learning that there is this difference is a burden on authors. But we might want to do what TabAtkins is advocating for, as well as additional things. In first case, we take the max, not very useful, might want<br> <Kurt> minimum, might want track to grow to limit, and not have extra space, which doesn't seem useful.<br> <fantasai> minmaxbasis(min, max, basis for repetition)<br> <Kurt> fantasai: To enable that, or other behaviors, we want to add some new syntax to do that, and I think there is room, we should investigate. One possibility is min-max-basis, which would give min, max, basis for repitition<br> <Kurt> fantasai: say "use minimum, use max, use combination", room to experiment<br> <miriam> repeat(auto-fit from 15em, minmax(whatever, whatever))<br> <fantasai> minmax(100px, 200px) minmax(100px, auto) minmax(auto, 200px) minmax(auto, auto)<br> <astearns> ack lea<br> <Kurt> fantasai: could be useful for authors, but fundamentally, if we want this to be a system that's understandable, it should be consistent between grid and grid lanes for all 4 syntaxes<br> <lea> - Consistency TAG principle https://www.w3.org/TR/design-principles/#consistency<br> <miriam> q+<br> <TabAtkins> Don't we also have a "but don't overvalue consistency with legacy behavior if better solutions exist now" policy?<br> <Kurt> lea: I'm not sure if I have enough background, but a high level requirement. I don't thinks witchning from masonry to grid is important, nice to have, but I don't see authors regularly switching. However, mental model is least surprise, what to expect when you use a syntax. I don't think he way minmax works is intuitive, hard to explain how it<br> <Kurt> works. Given that authors have an existing mental model, hesitant to change, even if we can do better. Especially because we put a lot fo work into the current model. Break precedent only if you're very certain you have a much better solution. Breaking precedent is an ergo problem, two different mental models. I tend to agree with fantasai. If we<br> <Kurt> ant a different behavior, we should have a different syntax in grid.<br> <fantasai> "There is often a tension between API ergonomics and consistency, when existing precedent is of poor usability. In some cases it makes sense to break consistency to improve usability, but the improvement should be very significant to justify this." -- https://www.w3.org/TR/design-principles/#consistency<br> <Kurt> lea: I was thining, what could that look like, new syntax for both masonry and grid, some kind of switch that grid has access too, but default in masonry, but are the use cases around irregular grids, or all cols/rows having the same params, could introduce new property - could have grid-column-min-width to be bikeshedded, could be value<br> <Kurt> independently of masonry. Multicol has this really nice syntax, can set columns and width and browser figures it out. Could set property in grid, and get best of both worlds.<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to discuss additions to syntax<br> <astearns> ack miriam<br> <miriam> minmax(100px, min-content) minmax(100px, max-content)<br> <Kurt> miriam: seems like the one example you keep getting TabAtkins, makes sense, but feels somewhat contrived. Switch min-content for max-content, you probably want the other thing. I don't understand building around one use case when the other behavior is more useful. Overall, I would like to see more control. You might want either thing, so you should<br> <Kurt> add a control to have either thing. Should look into having grid-lanes and grid handle it either way.<br> <TabAtkins> to clarify, miriam, is your example "i want it to be min-content, but not get larger than 100px"?<br> <Kurt> astearns: summarizing, we have a bunch of solutions for both grid and grid-lanes in some future way and keeping limitations today. Tab is looking at a better solution tailored for grid-lanes. Would you be willing to resolve on consistency between grid and grid-lanes now, or hold on to making grid-lanes work for these cases<br> <Kurt> TabAtkins: I think it's the wrong behavior, but am open to a new control in the future<br> <Kurt> resolution: Keep consistency between grid and grid-lanes, work on a solution for both layout systems<br> <Kurt> RESOLVED: Keep consistency between grid and grid-lanes, work on a solution for both layout systems<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12573#issuecomment-3607769256 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 December 2025 16:41:07 UTC