That clause dates from the original Microsoft algorithm, see https://www.w3.org/TR/2014/WD-css-grid-1-20140513/#translated-algo

I think the reason it was included had something to do with wanting the flexible track to accommodate the spanning item, rather than making any adjacent auto tracks accommodate it: this makes the auto tracks more tightly wrapped around their contents while the flexible track grows. I'm not sure it's working as intended though. :/

So the confusion is between the results of case 2 (the fr column grows bigger than the container) and cases 4/5 (the fr column won't exceed the container).

This seems like an accidental result of the change we made to have 1fr imply an auto minimum - this has the desired effect in case 2 (the fr grows larger to accommodate the item's minimum size), but then the algorithm itself skips over the track when the item spans, so we don't get the opportunity to have the same effect.

Hmm, we don't want to lose the case 2 behavior, so we'll have to look into this and see if there's a reasonable way to make case 4/5 match expectations, without losing the intent of the original MS algo (make auto tracks tightly wrap and let fr tracks take up the slack).

OK, Tab and I looked over this issue. As far as we can tell, there are two principles here that we want to follow:

• Flexible tracks absorb spanning items' content, leaving auto tracks tightly-wrapped around their contents insofar as possible. (See [css-grid] Grid track sizing items spanning a flexible track #2177 (comment))
• Content-sized tracks such as auto tracks and flexible tracks with a minimum (e.g. minmax(min-content, 1fr) honor their minimum and ensure that no item spanning them causes overflow.

The current algorithm is failing at #2 because of its heuristic for #1. Consider a spanning item of 100px, a 50px-sized grid, and:

• Track sizing of minmax(auto, 1fr) minmax(max-content, 2fr)
• Track sizing of auto minmax(10px, 1fr)

In the first case, we're completely ignoring the minimums. In the second case, the first track sizes at 0px because it skips the spanning item, and the second track maxes out at 50px, causing the item to overflow the tracks.

We're not sure if there's a good way to fix this while adhering to both principles, since it seems to require resolving flexible tracks and then cycling back to re-resolve intrinsic track sizes. We'd like to hear back from the Microsoft folks who developed the algorithm on what they think about this situation. @atanassov?

It seems I'm affected by this [1], so I hope that @atanassov et al can resolve this 😀(and that everything will be consistent in browsers soon, eg via test-cases & browser-tickets)

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=817329
(Mainly: I want the text to fill the whole available width.)

Some of the original reasoning for the behavior (at least looking through some old test cases) suggests this was intended for scenarios where a spanning header was supposed to influence the size of columns in an article. I don't believe we have a strong reason and/or content that depends on this behavior at this point so we could go either way.

Assuming we want to keep the exception, it'd be good to explore tweaking the heuristic with something like:

• Spanners that cross tracks that have content-based mins AND flexible maxes only contribute content sizes to those tracks; otherwise they participate normally.

Since flexible tracks now have auto minimums by default, this will ensure that spanners crossing flexible tracks only contribute to non-flexible tracks if all the flexible tracks have explicit fixed mins. It seems like that embodies the spirit of the original heuristic (spanners typically rely on flexible tracks to fit) while also satisfying the requirement that items crossing content-sized tracks shouldn’t overflow their tracks.

The Working Group just discussed Grid track sizing items spanning a flexible track, and agreed to the following resolutions:

• RESOLVED: edit in Rossen proposal in https://github.com/w3c/csswg-drafts/issues/2177

OK, Tab and I edited in some changes to address this case. The changes are a little more complicated than what Rossen outlined, because we realized we needed to intelligently handle the case of the item spanning multiple tracks sized with fr units. :)

@MatsPalmgren @mrego @atanassov Please review the changes and let us know if they seem OK? 25e3f63 Thanks~

I might have missunderstood the proposed change but I think something like that does not work at least for three reasons. I'll use an example to illustrate what I mean:

<div style="display:grid; grid-template-columns: 1fr auto 2fr">
     <div style="width: 50px; grid-column: 2/4;"></div>
     <div style="width: 100px; grid-column: 1/3;"></div>
     <div style="width: 90px; grid-column: 1/4;"></div>
</div>

(I don't specify a width for the grid container. Let's just assume that we have exactly the amount of free space required by the examples not to enlarge tracks in "Expand flexible tracks" step)

If we apply a change like the one proposing we'd be breaking at least 2 principles & 1 heuristic of grid:

• Order independence
• fr tracks must retain their respective proportions
• Tightly-wrapped tracks

In this example, procesing the items in this source code order will generate the following result

1. the 50px item sizes the tracks to [0 0 50]
2. the 100px item sizes them to [100 0 50]
3. the 90px one fits and there is no need to enlarge tracks

Instead should we process the third item in the first place we'd have:

1. the 90px item sizes the tracks to [30 0 60]
2. the 50px item fits in [30 0 60]
3. the 100px one sizes the tracks to [100 0 60]

In none of the two cases the grid is tightly packed. Agreed that's a desirable effect from the heuristics but not a requirement. However as you can see, relative proportions of fr tracks are not preserved and order independence is also broken.

@svillar I think you're missing one of two things: 1) The space distributing algorithm maintains the planned increase separately from the track sizes subtracted out to find the space to distribute exactly so that we don't have this order dependence. 2) The step we added invokes space distribution for all items spanning flexible tracks at once (“together, rather than grouped by span size”) so that the planned increase isn't cleared out between them--i.e. items spanning flexible tracks aren't ordered by span size, as other items are.

So the processing of items will generate the following result:

1. The 50px item folds into the planned increase -> [0 0 50].
2. The 100px item folds into the planned increase -> [100 0 50].
3. The 90px item folds into the planned increase -> [100 0 60].
4. The planned increase is added to the track sizes (currently [0 0 0]) yielding [100 0 60] at the end of intrinsic track sizing.
5. If there is space available afterwards, the Expand Flexible Tracks step inflates the 60px track to match the ratios, yielding [100 0 200] (or as close to it as it can get given the limits of available space).

The algorithm preserves order independence. It doesn't maintain the fr ratios when there isn't space to do so, this is intentional. It isn't tightly packed always, as in this example--in order that simple cases with spanning item being the largest maintain their ratios insofar as possible in the available space.

Does this clear things up?

(Agenda+ to request WG review of changes.)

Ah OK, then I had clearly missunderstood the changes.

The Working Group just discussed Grid track sizing items spanning a flexible track, and agreed to the following resolutions:

• RESOLVED: Grid items spanning fr tracks do contribute to fr resolution for intrinsic sizes with the addition that fr tracks not 1 to 1 ratio get contributed to based on that ratio.

OK @svillar :) Let me know if the spec needs clarification, though.

I've a question about this change, on a previous comment you said:

• Content-sized tracks such as auto tracks and flexible tracks with a minimum (e.g. minmax(min-content, 1fr) honor their minimum and ensure that no item spanning them causes overflow.

But the change affects also non-spanning items, see https://drafts.csswg.org/css-grid/#algo-single-span-items:

2. Size tracks to fit non-spanning items: For each track with an intrinsic track sizing function and not a flexible sizing function, ...

Now it says "and not a flexible sizing function" so if we have a non-spanning item on a flexible track. The item could end up overflowing the track as their contents would be ignored.
Check the discussion in the following bug for an example:
https://bugzilla.mozilla.org/show_bug.cgi?id=1381512#c6

Do we really want this behavior for non-spanning items?

@mrego Yes, those are now handled together with other items that span flexible tracks in https://drafts.csswg.org/css-grid-1/Overview.html#algo-spanning-flex-items

I think this makes sense? Let me know if it doesn't make sense. :) Certainly it shouldn't be overflowing.

Yes, I think that makes sense. I missed that part, that would avoid overflow in that case. Thanks.