[css-grid] Growth limits not increased with min-content contributions of spanning items

[Loirooriol]

If you have a non-spanning item, https://drafts.csswg.org/css-grid/#algo-single-span-items

• For min-content maximums:
  If the track has a min-content max track sizing function, set its growth limit to the maximum of the items’ min-content contributions.

But for spanning items, https://drafts.csswg.org/css-grid/#algo-spanning-items

• For intrinsic maximums: Next increase the growth limit of tracks with an intrinsic max track sizing function by distributing extra space as needed to account for these items' minimum contributions. [...]

Why do we distribute the min-content contribution in the former case, but only the minimum contribution in the latter?

.grid { display: grid }
.grid.one { grid-template-columns: minmax(0, min-content) }
.grid.two { grid-template-columns: repeat(2, minmax(0, min-content)) }
.grid > .item { min-width: 0; background: cyan }
.grid.two > .item { grid-column: span 2 }

<div class="grid one">
  <div class="item">Foo</div>
</div>
<div class="grid two">
  <div class="item">Foo</div>
</div>

looks like

Thus violating

Note: This step is a simplification of the steps below for handling spanning items, and should yield the same behavior as running those instructions on items with a span of 1.

[Loirooriol]

Note that intrinsic max track sizing functions can only be min-content or max-content (auto is treated as max-content). So we should just distribute the min-content contribution instead of the minimum contribution.

[fantasai]

This was an error introduced in f48098c and it needs to be reverted.

[Loirooriol]

Even if this was an unintentional error, it has been implemented by Chromium, WebKit, Firefox, and old Edge.
So I hope reverting to the sane behavior will still be web compatible.

[fantasai]

@Loirooriol You're right. Here's a live testcase. The specified behavior is absurd, though. I'm surprised no one else noticed it's wrong. :(

Agenda+ to confirm the correction.

[css-meeting-bot]

The CSS Working Group just discussed Growth limits not increased with min-content contributions of spanning items.

RESOLVED: Accept the edits made to the ED re minimum vs min-content (and add WPT tests)

The full IRC log of that discussion

<AmeliaBR> Topic: Growth limits not increased with min-content contributions of spanning items
<AmeliaBR> github: https://github.com//issues/4790#issuecomment-664068575
<fantasai> https://drafts.csswg.org/css-grid-1/#algo-content
<AmeliaBR> fantasai: This will make more sense if I pull up the relevant section of the spec. ↑
<AmeliaBR> ... There are several sections in how we handle intrinsic sizes. Minimums first, then maximums. For minimums, there's auto and minimum/maximum. For maximums, there's no auto.
<AmeliaBR> ... When we edited the spec recently to add new terminology, we accidentally said “minimum” when we meant “min-content”. But when we went to fix that, discovered someone had implemented as written, so need to confirm the reversion.
<AmeliaBR> ... The current text is rather non-sensical. It's very rare/weird that min-content would be specified as the maximum value of your minmax range. We should fix it.
<AmeliaBR> astearns: Anyone have actual web compat information measured? Or should we change & see if we get negative feedback.
<AmeliaBR> oriol: I do know there is no WPT for the bad behavior, although there is a Chromium internal test.
<fremy> sounds unexpected to me
<AmeliaBR> fantasai: I can't see any reason why anyone would write this code, with min-content in the max side of a minmax function.
<AmeliaBR> fremy: I don't expect people would do that. We should be able to fix this.
<AmeliaBR> PROPOSAL: Accept the edits made to the ED re minimum vs min-content (and add WPT tests)

[Loirooriol]

This seems covered by WPT css-grid/layout-algorithm/grid-intrinsic-track-sizes-001.html