My thoughts are:

• Limiting the growth limit by the fit-content() argument only when handling max-content maximums but not when handling all intrinsic maximums (including max-content) seems an oversight. It should happen in both cases.
• When the growth limit of a fit-content() track reaches the fit-content() limit and stops growing, we should try to grow other tracks to compensate (option B in the previous post).
• We should try to respect fit-content() limits when accommodating minimums up to growth limits. Sure, minimums take precedence over maximums in case of conflict, but if we can distribute into other tracks, it makes sense to to so. E.g. if we are distributing 100px among 2 tracks fit-content(10px) and auto with infinite growth limits, then 10px 90px makes more sense than 50px 50px. If necessary, we can always grow beyond the fit-content() limit when distributing space beyond growth limits, thanks to the "if there are no such tracks, then all affected tracks".

So I propose something like:

@@ -4161,8 +4161,6 @@ Resolve Intrinsic Track Sizes</h3>
           a <a>max track sizing function</a> of ''max-content''
           by <a href="#extra-space">distributing extra space</a> as needed
           to account for these items' <a>max-content contributions</a>.
-          However, limit the growth of any ''fit-content()'' tracks
-          by their ''fit-content()'' argument.
       </ol>
 
       Repeat incrementally for items with greater spans until all items have been considered.
@@ -4233,13 +4231,15 @@ Distributing Extra Space Across Spanned Tracks</h4>
           <pre><var>extra-space</var> = max(0, <var>size-contribution</var> - ∑<var>track-sizes</var>)</pre>
 
         <li>
-          <strong>Distribute space to base sizes up to growth limits:</strong>
+          <strong>Distribute space to base sizes up to limits:</strong>
           Find the |item-incurred increase| for each spanned track with an affected size
           by: distributing the space equally among such tracks,
           freezing a track’s |item-incurred increase|
           as its affected size + |item-incurred increase|
-          reaches its <a>growth limit</a>
-          (and continuing to grow the unfrozen tracks as needed).
+          reaches its <a>growth limit</a>.
+          Also freeze ''fit-content()'' tracks
+          when they reach their ''fit-content()'' argument.
+          In both cases, continue to grow the unfrozen tracks as needed.
 
           If a track was marked as <a>infinitely growable</a> for this phase,
           treat its <a>growth limit</a> as infinite for this calculation
@@ -4265,7 +4265,8 @@ Distributing Extra Space Across Spanned Tracks</h4>
               if there are no such tracks, then all affected tracks.
             <li>
               when handling any intrinsic <a>growth limit</a>:
-              all affected tracks.
+              any affected track that happens to also have an intrinsic <a>max track sizing function</a>;
+              if there are no such tracks, then stop distributing space.
           </ul>
 
           For this purpose, ''fit-content()'' tracks are treated as ''max-content''

CC @MatsPalmgren @fantasai

After careful review, we actually think the spec is already complete and correct in this regard. The "Distribute extra space" algo already handles fit-content() explicitly, in exactly the way we want, in step 3. We very purposely do not want to apply fit-content() clamping to base sizes, because fit-content is supposed to respect its minimum size (here reflected as an "auto" min track sizing function) more strongly than either its specified or maximum size. All we want to do is treat the track like its max sizing function is "max-content" (thus affecting only the growth limit), unless that would make it larger than the specified length.

However, the line at the end of the "max-content maximums" steps in steps 2 and 3 of Resolve Intrinsic Sizes is misleading - as your own confusion shows, it implies something additional needs to be done, when actually it's an editorial statement referring to the fit-content() handling already done in the Distribute Extra Space algo. We'll remove those.

(That said, we've found several other minor mistakes or necessary clarifications in these sections while reviewing. :( )

We very purposely do not want to apply fit-content() clamping to base sizes

Sure, fit-content is supposed to respect its minimum size. But IMO this should happen in step "3. Distribute space beyond growth limits" of the the Distribute Extra Space algo, not in "2. Distribute space to base sizes up to growth limits".

Because fit-content(100px) is like the minimum between minmax(auto, 100px) and minmax(auto, max-content), and for the former one, step 2 won't go beyond 100px. It will try to distribute among other tracks first.

Also "Size tracks to fit non-spanning items" doesn't use the Distribute Extra Space algo. So that removal seems wrong.

Because fit-content(100px) is like the minimum between minmax(auto, 100px) and minmax(auto, max-content), and for the former one, step 2 won't go beyond 100px. It will try to distribute among other tracks first.

Right, that sentence says "essentially" because it's editorial and not precise. fit-content(100px) is very purposely not exactly like minmax(auto, 100px), because we don't want it to clamp the minimum size to a max of 100px.

because we don't want it to clamp the minimum size to a max of 100px.

Sure, we don't want to clamp to a max of 100px when distributing min contributions, because min wins over max.

But we do want to clamp when distributing max contributions. Otherwise fit-content(100px) would behave exactly like minmax(auto, max-content)!

So, imagine

• You have two tracks: fit-content(100px) and 0px.
• The grid has a definite size (not sizing under a min/max-content constraint)
• There is a grid item spanning both tracks. The item has a minimum contribution of 0, so the base size of the tracks stay at 0. But the item has a max-content contribution of 300px, and we distribute that into fit-content(100px).

After your change, the fit-content(100px) gets all the 300px into its growth limit. So the 100px argument is totally ignored.
Here it should definitely be clamped.

Another case:

• You have two tracks: fit-content(100px) and max-content.
• The grid has a definite size (not sizing under a min/max-content constraint)
• There is a grid item spanning both tracks. The item has a minimum contribution of 300px, and we distribute that among the base sizes of the tracks.

With the current spec, both tracks will end up with a base limit of 150px (since currently they have an infinite growth limit).

What I'm saying is that the fit-content(100px) track should get 100px, and the remaining 200px should go to the max-content track.

But of course, if there was no other track which could take these 200px, they definitely should end up going to the fit-content(100px) track, because min wins over max. I'm not arguing against that.

@Loirooriol OK, I see what you're saying. I think the spec is clear (fit-content() limits only affect the growth limits, not the base sizes), but agree that it's sub-optimal when distributing the minimum contribution of spanning items. It wasn't a case we considered very carefully.

@fantasai OK, so now

• Non-spanning algorithm has been restored in 4f4fde9, it's fine now.

• Spanning algorithm still needs to clamp the growth limits, because https://drafts.csswg.org/css-grid/#extra-space says

  Distribute space beyond growth limits: If space remains after all tracks are frozen, unfreeze and continue to distribute space to the item-incurred increase of…

  • when handling any intrinsic growth limit: all affected tracks.

  So it doesn't matter that a when fit-content() track reaches its limit, it's treated as a fixed function. Because the spec still says "all affected tracks", and the fit-content() doesn't stop being an affected track even when it reaches its limit.

  That's why I proposed

  @@ -4265,7 +4265,8 @@ Distributing Extra Space Across Spanned Tracks</h4>
                 if there are no such tracks, then all affected tracks.
               <li>
                 when handling any intrinsic <a>growth limit</a>:
  -              all affected tracks.
  +              any affected track that happens to also have an intrinsic <a>max track sizing function</a>;
  +              if there are no such tracks, then stop distributing space.
             </ul>
   
             For this purpose, ''fit-content()'' tracks are treated as ''max-content''

• The distribution of base sizes in the spanning algorithm is still not taking fit-content() limits in an optimal way, but I'm fine with deferring the improvements to the future.

Thinking better about this, in common cases the spanning algorithm doesn't clamp with fit-content limits at all. Which is bad.

#grid {
  display: grid;
  width: 200px;
  grid-template-columns: fit-content(25px) 0px;
}
#item {
  grid-column: span 2;
  min-width: 0;
}
#item::before, #item::after {
  content: '';
  height: 50px;
  width: 50px;
  float: left;
}

<div id="grid">
  <div id="item"></div>
</div>

We run the spanning algorithm:

1. For intrinsic minimums: no-op, the minimum contribution is 0 because of min-width: 0.
2. For content-based minimums: no-op, no track with min-content min track sizing function.
3. For max-content minimums: no-op, no track with max-content min track sizing function.
4. No-op, the base size is 0, smaller than the infinite growth limit.
5. For intrinsic maximums: we distribute the min-content contribution (50px) into the growth limit.
   • Find the space to distribute: all these 50px.
   • Distribute space up to limits: no-op, the affected size is a growth limit and the track is not marked infinitely growable.
   • Distribute space beyond growth limits: the track takes 25px, then its treated as having a fixed max track sizing function.
     But this doesn't stop the track from being an affected track, and we are distributing among "all affected tracks".
     So the track takes all the 50px, ignoring the fit-content limit.
   • Result: the growth limit becomes 50px, and we flag the track as infinitely growable.
6. For max-content maximums: we distribute the max-content contribution (100px) into the growth limit:
   • Find the space to distribute: the growth limit is already 50px, so we only have to distribute the remaining 50px.
   • Distribute space up to limits: the limit is infinity because of the flag, so the track takes all the additional 50px, ignoring the fit-content limit.
   • Distribute space beyond growth limits: no-op, all space has been distributed
   • Result: the growth limit is increased by 50px, becoming 100px.

The 25px fit-content limit has been ignored, not just once but twice!

So either revert 64494c0 completely and leave the exact clamping procedure undefined for now, or apply my suggestions. But with the current spec no clamping is actually enforced.

@Loirooriol OK, Proposed fix:

diff --git a/css-grid-1/Overview.bs b/css-grid-1/Overview.bs
index ff3b12ef8..5fffa1b73 100644
--- a/css-grid-1/Overview.bs
+++ b/css-grid-1/Overview.bs
@@ -4263,8 +4263,6 @@ Resolve Intrinsic Track Sizes</h3>
 a <a>max track sizing function</a> of ''max-content''
 by [[#extra-space|distributing extra space]] as needed
 to account for these items' <a>max-content contributions</a>.
-However, limit the growth of any ''fit-content()'' tracks
-by their ''fit-content()'' argument.
 </ol>
 
 Repeat incrementally for items with greater spans until all items have been considered.
@@ -4341,7 +4339,9 @@ Distributing Extra Space Across Spanned Tracks</h4>
 For [=base sizes=],
 the |limit| is its [=growth limit=].
 For [=growth limits=],
-the |limit| is infinity if it is marked as [=infinitely growable=],
+the |limit| is
+the ''fit-content()'' argument if has a ''fit-content()'' [=track sizing function=],
+infinity if it is marked as [=infinitely growable=],
 and equal to the [=growth limit=] otherwise.
 
 Note: If the affected size was a <a>growth limit</a>
@@ -4351,7 +4351,8 @@ Distributing Extra Space Across Spanned Tracks</h4>
 <li>
 <strong>Distribute space beyond limits:</strong>
 If space remains after all tracks are frozen,
-unfreeze and continue to distribute space to the |item-incurred increase| of…
+unfreeze and continue to distribute space
+to the unfrozen |item-incurred increase| of…
 
 <ul>
 <li>
@@ -4372,7 +4373,7 @@ Distributing Extra Space Across Spanned Tracks</h4>
 the [=max track sizing function=] of a ''fit-content()'' track
 is treated as ''max-content''
 until it reaches the limit specified as the ''fit-content()'' argument,
-after which it is treated as having a <a>fixed sizing function</a> of that argument.
+after which it is frozen at that [=fixed sizing function=].
 
 Note: This step prioritizes the distribution of space

Let us know if this seems correct?

-However, limit the growth of any ''fit-content()'' tracks
-by their ''fit-content()'' argument.

Good!

-the |limit| is infinity if it is marked as [=infinitely growable=],
+the |limit| is
+the ''fit-content()'' argument if has a ''fit-content()'' [=track sizing function=],
+infinity if it is marked as [=infinitely growable=],

This doesn't seem entirely right. Because if a fit-content() track isn't marked as infinitely growable, I don't think it should grow here even if the fit-content limit is higher. Example:

.grid {
  display: grid;
  grid-template-columns: fit-content(100px) minmax(auto, max-content);
}
/* minimum contribution = 0px
   min-content contribution = 0px
   max-content contribution = 0px */
.grid-item-1 { grid-column: 1 / 2 }
.grid-item-2 { grid-column: 2 / 3 }

/* minimum contribution = 0px
   min-content contribution = 10px
   max-content contribution = 100px */
.grid-item-3 {
  grid-column: 1 / 3;
  min-width: 0;
}
.grid-item::before {
  content: "1234567890";
  line-break: anywhere;
  font: 10px/1 Ahem;
}

1. ¶12.5.2 takes care of the non-spanning items, their intrinsic contribution is 0, so they just set the growth limit to 0, without the infinitely growable flag.
2. ¶12.5.3.5 distributes the 10px among the growth limit of both tracks. So both growth limits become 5px.
3. ¶12.5.3.6 distributes the 100px among the growth limit of both tracks. 10px already done, so 90px remaining. With the proposed text, the limit for the fit-content track is 100px, and the limit for the other track is 5px.
4. Result: the fit-content track ens up with a growth limit of 95px, the other track with 5px. But fit-content(100px) is supposed to be the smallest of minmax(auto, 100px) and minmax(auto, max-content), so it shouldn't be bigger.

I would change it to:

the limit is equal to the growth limit if the track is not marked as infinitely growable, otherwise it's the ''fit-content()'' argument if it has a ''fit-content()'' track sizing function, or +infinity otherwise.

Next:

-unfreeze and continue to distribute space to the |item-incurred increase| of…
+unfreeze and continue to distribute space
+to the unfrozen |item-incurred increase| of…

-after which it is treated as having a <a>fixed sizing function</a> of that argument.
+after which it is frozen at that [=fixed sizing function=].

No, we don't want to freeze permanently. Consider this case:

when accommodating minimum contributions or accommodating min-content contributions: any affected track that happens to also have an intrinsic max track sizing function; if there are no such tracks, then all affected tracks.

When the base sizes reach the fit-content limit, we want to stop considering them as having "an intrinsic max track sizing function". However, if we run out of tracks, we still want to distribute into them ("if there are no such tracks, then all affected tracks"). If we freeze, and only distribute to the unfrozen, we will skip them.

Actually, we only want to freeze in this case:

when handling any intrinsic growth limit: all affected tracks.

So I would stick with my old proposal of

@@ -4265,7 +4265,8 @@ Distributing Extra Space Across Spanned Tracks</h4>
               if there are no such tracks, then all affected tracks.
             <li>
               when handling any intrinsic <a>growth limit</a>:
-              all affected tracks.
+              any affected track that happens to also have an intrinsic <a>max track sizing function</a>;
+              if there are no such tracks, then stop distributing space.
           </ul>
 
           For this purpose, ''fit-content()'' tracks are treated as ''max-content''

or, if you want to freeze, let's split that step into 2:

3. Distribute space beyond limits (1): If space remains after all tracks are frozen, unfreeze and continue to distribute space to the unfrozen item-incurred increase of…

   • when accommodating minimum contributions or accommodating min-content contributions or handling any intrinsic growth limit: any affected track that happens to also have an intrinsic max track sizing function.
   • when accommodating max-content contributions: any affected track that happens to also have a max-content max track sizing function.

   For this purpose, the max track sizing function of a fit-content() track is treated as max-content until it reaches the limit specified as the fit-content() argument, after which after which it is frozen at that fixed sizing function.

4. Distribute space beyond limits (2): If space remains, and handling any intrinsic base size, unfreeze and continue to distribute space to the item-incurred increase of all affected tracks.

BTW, while we are at it, this "it" is not much clear:

For this purpose, the max track sizing function of a fit-content() track is treated as max-content until **it** reaches the limit specified as the fit-content() argument, after which it is treated as having a fixed sizing function of that argument.

I guess it should be "the affected size + item-incurred increase". And afterwards there is another "it" which refers to something else, "the track" or "the max track sizing function", so it may be good to make that explicit too.

Oh, and

 For [=base sizes=],
 the |limit| is its [=growth limit=].

should probably be the smaller of the growth limit an the fit-content limit (if any). Because the growth limit is initially set to infinity for fit-content tracks. In other cases, the growth limit being greater than the fit-content limit should mean that the base size forced that, that is we already have base size = growth limit, so choosing limit := growth limit or something smaller doesn't matter.

Or alternatively, just initialize the growth limit of fit-content tracks to their argument (instead of infinity) in §12.4? This would also imply that fit-content tracks would never be marked as infinitely growable, avoiding the need to special-case them when finding the limit when distributing into growth limits. Edit: this would be simpler but may make fit-content tracks take more a bigger contribution than max-content tracks, breaking the principle that fit-content(limit) should be the minimum of minmax(auto, limit) and minmax(auto, max-content).

@Loirooriol Proposed edits:

diff --git a/css-grid-1/Overview.bs b/css-grid-1/Overview.bs
index 4c8543864..bd499e5a8 100644
--- a/css-grid-1/Overview.bs
+++ b/css-grid-1/Overview.bs
@@ -4278,8 +4278,6 @@ Resolve Intrinsic Track Sizes</h3>
 					to the [=growth limits=] of tracks with
 					a <a>max track sizing function</a> of ''max-content'',
 					to accommodate these items' <a>max-content contributions</a>.
-					However, limit the growth of any ''fit-content()'' tracks
-					by their ''fit-content()'' argument.
 			</ol>
 
 			Repeat incrementally for items with greater spans until all items have been considered.
@@ -4370,10 +4368,15 @@ Distributing Extra Space Across Spanned Tracks</h4>
 						(and continuing to grow the unfrozen tracks as needed).
 
 						For [=base sizes=],
-						the |limit| is its [=growth limit=].
+						the |limit| is its [=growth limit=],
+						  capped by its ''fit-content()'' argument if any.
 						For [=growth limits=],
-						the |limit| is infinity if it is marked as [=infinitely growable=],
-						and equal to the [=growth limit=] otherwise.
+						the |limit| is the [=growth limit=]
+						  if the [=growth limit=] is finite
+						  and the track is not [=infinitely growable=],
+						otherwise its ''fit-content()'' argument
+						  if it has a ''fit-content()'' [=track sizing function=],
+						and infinity otherwise.
 
 						Note: If the |affected size| was a <a>growth limit</a>
 						and the track is not marked [=infinitely growable=],
@@ -4400,14 +4403,16 @@ Distributing Extra Space Across Spanned Tracks</h4>
 							<li>
 								when accommodating any contribution
 								into [=growth limits=]:
-								all |affected track|s.
+								any |affected track| that has an intrinsic [=max track sizing function=].
 						</ul>
 
 						For this purpose,
 						the [=max track sizing function=] of a ''fit-content()'' track
 						is treated as ''max-content''
-						until it reaches the limit specified as the ''fit-content()'' argument,
-						after which it is treated as having a <a>fixed sizing function</a> of that argument.
+						until the track reaches the limit specified as the ''fit-content()'' argument,
+						after which its [=max track sizing function=] is treated as being
+						a <a>fixed sizing function</a> of that argument
+						(which can change which tracks continue to receive space in this step).
 
 						Note: This step prioritizes the distribution of space
 						for accommodating |size contribution|s

These changes aim to:

• clarify how the fit-content() limit caps the growth limit (at no point is it ever larger than a minmax(auto, [limit]) track)
• apply the fit-content() limit as a cap when distributing space to base sizes, so that we don't blow past the fit-content() limit if other spanned tracks have infinite growth limits (but don't give it more space than a minmax(auto, max-content) track would get otherwise)

The overall principle is to match the smaller of minmax(auto, max-content) and minmax(auto, <var>limit</var>), similar to how width: fit-content(<var>limit</var>) is defined as max(min-content, min(max-content, <var>limit</var>)).

If this looks good to you, we'll raise it to the WG for review!

LGTM!

Agenda+ to approve #4549 (comment)

The CSS Working Group just discussed [css-grid] Unclear how to limit track growth by fit-content() argument, and agreed to the following:

• RESOLVED: accept the current edits for fit-content growth limits