I think key word in "If the max is less than the min, then the max will be floored by the min" is "will", meaning that some other spec text will say how/when that's applied. Indeed, this is what falls out from the "if the growth limit is less than the base size, increase the growth limit to match the base size" which is applied at various stages through the Track Sizing Algorithm. The auto-repeat spec text in your first quote discuss min/max track sizing functions separately without mentioning any flooring though, so I think current UAs are correct in not applying it in this case. However, I agree that it's a reasonable change to add an explicit flooring step there. I'd prefer if the spec continues to make that explicit in each case though, so that it's clear when in the algorithms it should be applied (we've agreed on that in a previous spec issue, IIRC). Otherwise, I fear that it's open to interpretation when to apply it and that might lead to different rendering results.

I think key word is "will", meaning that some other spec text will say how/when that's applied.

That's right, see #3567. The min and max cannot always be compared a priori, so each time we handle max<min needs to be explicitly defined.

I agree the proposal makes sense, i.e.

• If both the min and max track sizing functions are definite, use the maximum of them
• If only one track sizing function is definite, use that one

And I think there is the remaining case of both sizing functions being indefinite, like a grid container with width: max-content; max-width: 100px; grid-template-columns: repeat(auto-fill, 50%). This falls into this case because the max size is definite, but the preferred size is intrinsic, so the percentage track size is initially treated as auto, right?

And I think there is the remaining case of both sizing functions being indefinite

The first sentence of the spec says:

if the grid container has a definite size or max size in the relevant axis

So if the grid container size is indefinite, then we don't calculate the number of repetitions, even if they have a fixed size like repeat(auto-fill, 100px).

The first sentence of the spec says:

if the grid container has a definite size or max size in the relevant axis

But max-width: 100px is definite so the condition holds, even if width is indefinite, doesn't it?

OK, updated the spec to floor the max by the min. Agenda+ to confirm.

Split out the issue of resolving percentages in the indefinite-width, fixed-max-width case as #4480

@MatsPalmgren does that text look good to you?

Yup, the new text looks clear to me.

I have tried to read all discussions here (BugZilla), here (Chromium), and in this issue, but please forgive me if I missed the answer to the following question: does this update will also resolve the following case, or should I fill a new ticket? This is a minimal reproduction of the CodePen used by Rachel Andrew to explain minmax() on its personal website. I think it's also used in the ticket from BugZilla.

What is the expected behavior?

Each grid item should have a minimum width of 200px.

What went wrong?

When resizing the window, the min value in minmax() might be ignored for "B" and/or "C", ie. grid items placed before an "overflowing" area (grid cell-s-) generated by a spanning grid item.

@cdoublev When the window is small enough, repeat(auto-fill, minmax(200px, 1fr)) will only produce a single explicit column, otherwise there would be overflow. Then, item D has a span of 3, so 2 implicit columns are added at the end. These implicit columns are not sized with minmax(200px, 1fr), they obey the grid-auto-column property instead, which defaults to auto. To achieve your desired behavior, use grid-auto-columns: minmax(200px, 1fr).

Thank you for this clarification. I would have thought that it makes more sense to create a new row and preserve the min value in minmax(), but I guess it would make an exception to the placement behavior.

Anyway, I'm not trying to achieve a particular behavior. I was just revisiting auto-fit/auto-fill behaviors, by reading Rachel's blog post, and I was "surprised" by the min value not being respected.

The CSS Working Group just discussed Overflow with auto-repeat and minmax(), and agreed to the following:

• RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/4043