Re: [csswg-drafts] [css-grid-3][Masonry] repeat(auto-fill) and minmax() (#12573)

The CSS Working Group just discussed `[css-grid-3][Masonry] repeat(auto-fill) and minmax()`.

<details><summary>The full IRC log of that discussion</summary>
&lt;ntim> scribe+<br>
&lt;ntim> alisonmaher: In the grid spec:<br>
&lt;ntim> Accoriding to css-grid-2, "For this purpose, each track is treated as its max track sizing function if that is definite or else its min track sizing function if that is definite. If both are definite, floor the max track sizing function by the min track sizing function. If neither are definite, the number of repetitions is one."<br>
&lt;ntim> The previous resolution: we decided to allow intrinsic auto-repeats in masonry which means that we'll likely want to consider this<br>
&lt;ntim> s/consider/reconsider<br>
&lt;TabAtkins> q+<br>
&lt;alisonmaher>  repeat(auto-fill, auto) is the same as repeat(auto-fill, minmax(auto, auto)<br>
&lt;astearns> ack fantasai<br>
&lt;ntim> fantasai: in grid, we don't have the ability to have 2 intrinsic sizes in the min and max<br>
&lt;TabAtkins> in an auto-repeat<br>
&lt;ntim> you must have either a min or a max definite size<br>
&lt;ntim> For the sizes valid in level 2 , we should keep the same grid behavior for masonry in level 3<br>
&lt;ntim> The case where both are intrinsic is new, and we can do whatever we want<br>
&lt;ntim> so when we have 2 definite sizes, we get the maximum, makes sense to do the same for intrinsic<br>
&lt;ntim> We can add a keyword in the future if we want to use the min<br>
&lt;astearns> ack TabAtkins<br>
&lt;ntim> TabAtkins: I don't like what Elika said, because masonry can assign heuristic values to its intrinsic keywords, we can treat them the same as the fixed sizes regardless of the position<br>
&lt;ntim> we also shouldn't treat the sizes differently in a mixed intrinsic case vs a double case<br>
&lt;ntim> when we last discussed, a couple of people agreed, but not fantasai, wanted to wait for miriam's opinion.<br>
&lt;ntim> it's 3 months later, we should resolve<br>
&lt;ntim> fantasai: The treatment we're deciding on here is not the actual size of the track, this is just an estimate we're using for how many tracks we have<br>
&lt;ntim> ...once we have the number of tracks, then we will fully resolve the tracks including intrinsic sizes<br>
&lt;ntim> ...I feel very strongly that for a given track listing, if I do that in grid / grid-lanes, I should get the same number of tracks, for the same set of sizes<br>
&lt;ntim> TabAtkins: same discussion from August<br>
&lt;ntim> miriam: it would be good to see demos, intrinsic sizing is sketchy for this<br>
&lt;ntim> fantasai: there's 2 questions: what to do for existing syntax? what do we do for the new one for double intrinsic?<br>
&lt;ntim> I don't mind for double<br>
&lt;ntim> ???<br>
&lt;ntim> miriam: in theory i agree, but in practice I haven't seen demos<br>
&lt;ntim> i don't know why we would choose one over the other<br>
&lt;alisonmaher> q+<br>
&lt;ntim> TabAtkins: fantasai is making an argument for consistency, but i'm also doing the same on the other axis<br>
&lt;TabAtkins> Elika wants "Grid and Masonry act identically for the syntaxes that are actually valid in both". I want "Masonry always acts the same for intrinsic keywords, regardless of how you use them".<br>
&lt;ntim> alisonmaher: last time we talked about this, we did a whiteboard, and visuals are really helpful here<br>
&lt;TabAtkins> That is, `repeat(auto-fill, auto)` works in Masonry (finds a heuristic size, uses that to determine repeats).<br>
&lt;alisonmaher> q-<br>
&lt;ntim> miriam: if the argument for consistency is that auto means minmax(auto, auto), then it's more obscure<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to clarify sizing vs counting<br>
&lt;ntim> TabAtkins: that's not the whole reason, is that repeat(auto-fill, auto) has a meaning in masonry, but not in grid<br>
&lt;ntim> but repeat(auto, auto) has a meaning in masonry that we agree on and is invalid in grid<br>
&lt;kbabbitt> Table from the August F2F: https://usercontent.irccloud-cdn.com/file/DqXUz9TL/IMG_2299.png<br>
&lt;ntim> I think it's weird if minmax(0px, auto) acts differently from either of these two, because suddenly it's 0px which is what it is in grid<br>
&lt;fantasai> "which is what it is in grid" as it should be!<br>
&lt;ntim> miriam: just in terms of determining repeats, not sizes<br>
&lt;astearns> ack fantasai<br>
&lt;ntim> fantasai: Tab just said repeat(auto, auto) is invalid in grid, but we're going to make it syntactically useful in grid, and we should give it an useful meaning. If there's no compat concern we should give it a meaning that is consistent across both grid &amp; masonry<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-3525669799 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 November 2025 06:13:21 UTC