[css-grid] Distribute extra space into non-intrinsic tracks instead of going beyond growth limits

[Loirooriol]

From https://drafts.csswg.org/css-grid/#extra-space,

2. Distribute space to base sizes up to growth limits: Find the item-incurred increase for each spanned track with an affected size by: distributing the space equally among such tracks
3. Distribute space beyond growth limits: If space remains after all tracks are frozen, unfreeze and continue to distribute space

However, the item could be spanning a track without intrinsic sizes whose base size still hasn't reached its growth limit. Wouldn't it make more sense to increase the base size of such track before increasing intrinsic tracks beyond growth limits?

For example, https://jsfiddle.net/phrwn2cd/

.grid {
  display: grid;
  grid-template-columns: minmax(0, 100px) minmax(auto, 100px);
  width: 0;
}
.item {
  grid-column: 1 / 3;
  width: 250px;
  height: 100px;
  background: cyan;
}

The columns are 0px 250px but instead I would expect 100px 150px, i.e.

2. Distribute space to affected base sizes up to growth limits
3. Distribute space to non-affected base sizes of spanned tracks up to growth limits
4. Distribute space beyond growth limits

[fantasai]

Your proposed algorithm would assign too much space to the intrinsic spanned tracks, ignoring the fixed tracks. For example, if I distribute 100px between those two columns, I'd get 0px 100px. Is that really what's wanted?

[fantasai]

I guess it's how it works currently, though...

[Loirooriol]

Yes, currently no contribution is distributed into such fixed tracks. I think it should happen at least if the intrinsic tracks reach their growth limits, but I'm open to taking it further and distribute equally from the very beginning.

[dholbert]

CC @MatsPalmgren

[css-meeting-bot]

The CSS Working Group just discussed Distribute extra space into non-intrinsic tracks instead of going beyond growth limits, and agreed to the following:

• RESOLVED: When calculating content based base sizes of spanning items, if extra space needs to be distributed past the growth limit, and there is a range available in another column, put it in there

The full IRC log of that discussion

<heycam> Topic: Distribute extra space into non-intrinsic tracks instead of going beyond growth limits
<heycam> github: https://github.com//issues/3648
<heycam> fantasai: let's say there are two columsn
<heycam> ... one is minmax(0, 100px), the other is minmax(auto, 100px)
<heycam> ... normally we do a first pass to figure out hte base size
<heycam> ... min size of each column
<heycam> ... first is fixed and gets 0
<heycam> ... the seoncd is roughlty hte min content contribution of any items in that column
<heycam> ... let's support that item is 150px
<heycam> ... the max specified here is 100px
<heycam> ... since the first column says I'm 0px, we put all 100 or 150px into the second column
<heycam> ... and blow out the maximum
<heycam> ... in order to fit the content
<heycam> ... but the author did give us some space, first column has a range
<heycam> ... instead of blowing out the max on the second column, we could take those 50px and put them into the first column
<heycam> ... and it wouldn't violate any of the max constraints on the columns
<heycam> ... we ran this idea by jensimmons_ and rachelandrew_ and they both said yeah we'd expect that to happen
<heycam> ... so I'm suggesting adjusting the grid alg so that when computing hte min size of a spanning item, if you hit the growth limit, and have another that is still be low its max, you increase that one
<heycam> TabAtkins: sounds reasonable
<heycam> rachelandrew_: I like this because it is more similar to the flex behavior, which people will expect
<heycam> ... why overflow the column when there is still space there
<heycam> ... this could happen when you have a single row grid, and they're using grid for whatever reason, and they'll expect that space to be used
<heycam> iank_: what happens if the item is 150px in width? are the columns 50px and 100px?
<heycam> fantasai: yes
<heycam> jensimmons_: right now they're 0 and 150 but we're proposing they be 50 and 100
<heycam> Rossen: any objections?
<heycam> RESOLVED: When calculating content based base sizes of spanning items, if extra space needs to be distributed past the growth limit, and there is a range available in another column, put it in there
<heycam> iank_: you'll need to specify which columns take the slack
<heycam> ... 2 on the left and 2 on the right
<heycam> fantasai: all of them

[fantasai]

Note to self: we need to be careful when editing to correctly handle minmax(0, min-content) minmax(max-content, 100px). (And should make sure there's a WPT for it.)

[tabatkins]

Upon reviewing other edits, we realized this was done slightly incorrectly - the "distribute beyond limits" part was meant to only distribute to preferred tracks when the alg is invoked with preferred tracks, but we accidentally wrote it to care about whether there are any preferred tracks. That is, passing a set of preferred tracks that happens to be empty will be treated the same as not passing preferred tracks at all; both will cause the distribution algo to go beyond limits for all affected tracks, which is not what we want. (If we try to pass preferred tracks, and there happen to not be any, it simply shouldn't distribute any space beyond limits.)

So we're still working on the wording a little, but we've fixed up the language to be more explicit about distinguishing between "didn't pass that argument" and "passed the argument, even if it's an empty list".