Repository navigation
[css-grid] minmax(auto,min-content) under a max-content constraint #3565
Description
Consider this grid: https://jsfiddle.net/xnvrk7h8/
.grid {
display: grid;
grid: auto / minmax(auto, min-content);
float: left;
border: 3px solid;
}
.item {
background: blue;
}
.float {
float: left;
width: 50px;
height: 50px;
}<div class="grid">
<div class="item">
<div class="float"></div>
<div class="float"></div>
</div>
</div>float: left sizes the grid under a max-content constraint (assuming the window is wide enough).
The grid item has a max-content width of of 100px when the floats are in the same line, and a min-content of 50px when they are in different lines.
According to https://drafts.csswg.org/css-grid/#algo-single-span-items,
If the track has an
automin track sizing function and the grid container is being sized under a min/max-content constraint, set the track’s base size to the maximum of its items’ min/max-content contributions, respectively, each limited by the max track sizing function if that is fixed and ultimately floored by its minimum contribution.
The track does have an auto min track sizing function and the grid container is being sized under a max-content constraint. So the track’s base size should be set to 100px. This is not limited by min-content because it's not fixed, and the minimum contribution is less than 100px:
The minimum contribution of an item is the outer size that would result from assuming the item’s used minimum size (min-width or min-height, whichever matches the relevant axis) as its preferred size (width or height, whichever matches the relevant axis) if its computed preferred size behaves as auto, or else the item’s min-content contribution.
Here the computed width is auto, and the used value of min-width: auto is the content size suggestion, 50px.
If the track has a
min-contentmax track sizing function, set its growth limit to the maximum of the items’ min-content contributions.
So the growth limit is initially set to 50px, but
if a track’s growth limit is now less than its base size, increase the growth limit to match the base size.
So both the base size and the growth limit should be 100px, the track is frozen, and the rest of the algorithm doesn't seem relevant.
However, this is not what implementations do:
Note that in Firefox the column is 50px wide but the grid container is 100px wide, so strange, @MatsPalmgren. This is solved by using min-width: 0 in the grid item, which alters the minimum contribution but shouldn't affect the result.
Is my understanding of the spec correct? Should it be changed to match implementations?
Activity
fantasai commentedon Jan 29, 2019
I think you're right, something's not right here. Probably the automatic minimum should be limited by min-content here.
fantasai commentedon Jan 29, 2019
OK, I think the correct edit here is to remove “if that is fixed” from the spec text you quote:
What do you think?
fantasai commentedon Jan 29, 2019
CC @MatsPalmgren
Loirooriol commentedon Jan 29, 2019
I don't think the sentence makes sense without “if that is fixed”, because it's not clear how a length should be limited by something which is not a length or a resolveable percentage.
For example, if the max track sizing function is the keyword
max-content, it needs to be defined that in this case the limit is the item’s max-content contribution.It can also be a
<flex>value, and these are not obvious because at that pointfris not known yet.fantasai commentedon Jan 29, 2019
So “if that is fixed, else it's own min-content/max-content size if the max track sizing function is min-content/max-content” ?
Loirooriol commentedon Jan 29, 2019
Basically yes, but IMO the sentence would bee too long and a bit confusing, there is already a min/max-content dichotomy for the size constraint, one could think that the this min/max-content is also with respect to that.
I would prefer a refactoring like
[css-grid-1] Use min-content/max-content max track sizes as limits on…
fantasai commentedon Jan 29, 2019
OK, I split the sentence. Didn't refactor the whole thing, but did some editorial tweaking to try to make it clearer. Let me know if the edits look OK and we'll ask for WG review. :)
Loirooriol commentedon Jan 30, 2019
Your refactoring with "limited min-/max-content contribution" looks good too.
I'm just not sure about the use of "min-content/max-content size" instead of the preceding "min-/max-content contribution". Not much sure about the difference, I believe one is an inner size and the other an outer size, here you probably want the outer?
And when it says "else by it’s own min-content/max-content size if that is min-content/max-content", "that" seems to refer to the own size instead of to the max track sizing function. Consider repeating "max track sizing function" to make it clear.
[css-grid-1] Fix size/contribution error, clarify antecedent. #3565
fantasai commentedon Jan 30, 2019
You're right, that's clearly the wrong one. Done, and done. Thanks!!!
fantasai commentedon Jan 30, 2019
Agenda+ to review the proposal:
When sizing auto-minimum tracks under a min-/max-content constraint, we use the item's min-/max-content contribution. But we limit that contribution by the track's max size if it's fixed (length/resolved %). This change makes it so that we also limit the contribution in the case of a min-content/max-content max track size, which fixes Oriol's example above to yield more intuitive behavior.
The value we're using to represent such an intrinsic max track size is the item's own contribution to such a size, which is I think a sufficient proxy for the actual max track size.
CC @MatsPalmgren @mrego @javifernandez
fantasai commentedon Jan 30, 2019
@Loirooriol I think actually we can simplify to only do this for min-content max track sizes, limiting by max-content seems like it'd be a no-op?
37 remaining items
css-meeting-bot commentedon Jul 18, 2023
The CSS Working Group just discussed
[css-grid] minmax(auto,min-content) under a max-content constraint, and agreed to the following:RESOLVED: accept latest changeThe full IRC log of that discussion
<fantasai> See https://github.com//issues/3565#issuecomment-1638901643<bramus> TabAtkins: if you look at very first comment, oriol has a test case here with some example and the wg decided earlier that chrome and edge are correct here.
<bramus> … earlier we tried to implement that resolution in spec and we did it wrong, reverted, and did it again
<bramus> … issue ended up being simpler thatn we thought
<fantasai> Final fix was much simpler than we thought: https://github.com/w3c/csswg-drafts/commit/35ed93fc9296e6541e83c8cca4b705b7ba82c31a
<bramus> … we believe only problem was in handling non spanning items in a max content constraint was
<fantasai> s/max content/min content/
<bramus> … we were using the limitex max content size
<dholbert> s/limitex/limited/
<bramus> … we should have been using limited min content size when resolving base sizes of tracks
<bramus> … once we fixed that, algortihm made more sense in general
<fantasai> s/of tracks/of auto tracks/
<bramus> … this text also dated back to 2016 which was early in grid spec text, so we believe this was a mistake we made early on
<bramus> … this mistake was not copied over into spanning case but firefox behavior in previous issue was them doing the same thing in spanning case
<bramus> … if you do it in either case, it should be ok. we think spec text is ok now.
<bramus> astearns: you were nodding along?
<bramus> oriol: yeah, we discussed yeasterday and I think the current solution is the correct one
<bramus> astearns: other comments?
<bramus> astearns: proposed resolution to accept latest change as the solution to the earlier resolution
<bramus> astearns: objections?
<bramus> RESOLVED: accept latest change
yisibl commentedon Jan 23, 2024
Does this have a wpt test yet?
[GFC][Integration] Allow grid items that span multiple tracks.
[GFC][Integration] Allow grid items that span multiple tracks.
[GFC][Integration] Allow grid items that span multiple tracks.