You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-grid] span=1 and span>1 use different size contribution to 'auto' min-sizing #500
https://drafts.csswg.org/css-grid/#algo-content
Step 1 : "For auto minimums" says: If the track has an auto min 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.
In Step 2 : "For intrinsic minimums" there is no such special handling for 'auto' min-sizing.
It seems a bit odd that span=1 and span>1 items should contribute different sizes to 'auto' tracks.
Is this an oversight and that the above paragraph also applies to span>1 items for 'auto' min-sizing tracks?
I think this is handled by steps 2.2 and 2.3 there? We apparently thought it was better to split the auto-handling separately for the two cases in step 2, while step 1 handles it in one spot.
2.2 is labeled "For content-based minimums" which to me means
'min/max-content', so I find the label misleading (because the spec
text under it now also includes 'auto').
2.3 is labeled "For max-content minimums" which to me means
'max-content', so I find the label misleading.
Just to make sure I understand the span>1 handling of 'auto' correctly:
2.1 "For intrinsic minimums", clearly includes 'auto' (unconditionally),
so this means that an item that spans an 'auto' track first contributes
its min-size contribution under 2.1, then also (one of) its min/max-content
contribution under 2.2/2.3 (under intrinsic sizing).
So the net effect for 'auto' in 2.1 - 2.3 is slightly different from
the span=1 case due to the "Otherwise" there, is that intentional?
After thinking some more about the 'auto' case, I suspect that applying
both its min-sizing (2.1) and min/max-content (2.2/2.3) contributions
is probably correct for the span>1 case. We apply both contributions
for 'min-content' and 'max-content' too in the span>1 case, but not
in the span=1 case. So if the goal of these changes were "make 'auto'
min track sizes behave as 'min(max)-content' when sizing under
a min(max)-content constraint" then the current text looks correct.
If so, I think it would be equivalent to stating upfront that "if sizing under
a min(max)-content constraint then treat an 'auto' min track sizing
as a 'min(max)-content' track min sizing in the following rules"
(for any span).
Tab and I looked over this again and decided to handle it as you suggested in #500 (comment) ... in particular as 2.2 seems to have left out max-content constraint handling for auto, even though max-content is handled there, and that seems like an error.
Activity
tabatkins commentedon Sep 20, 2016
I think this is handled by steps 2.2 and 2.3 there? We apparently thought it was better to split the auto-handling separately for the two cases in step 2, while step 1 handles it in one spot.
fantasai commentedon Sep 20, 2016
Marking invalid; please re-open if this is incorrect. :)
MatsPalmgren commentedon Sep 20, 2016
2.2 is labeled "For content-based minimums" which to me means
'min/max-content', so I find the label misleading (because the spec
text under it now also includes 'auto').
2.3 is labeled "For max-content minimums" which to me means
'max-content', so I find the label misleading.
Just to make sure I understand the span>1 handling of 'auto' correctly:
2.1 "For intrinsic minimums", clearly includes 'auto' (unconditionally),
so this means that an item that spans an 'auto' track first contributes
its min-size contribution under 2.1, then also (one of) its min/max-content
contribution under 2.2/2.3 (under intrinsic sizing).
So the net effect for 'auto' in 2.1 - 2.3 is slightly different from
the span=1 case due to the "Otherwise" there, is that intentional?
MatsPalmgren commentedon Sep 20, 2016
After thinking some more about the 'auto' case, I suspect that applying
both its min-sizing (2.1) and min/max-content (2.2/2.3) contributions
is probably correct for the span>1 case. We apply both contributions
for 'min-content' and 'max-content' too in the span>1 case, but not
in the span=1 case. So if the goal of these changes were "make 'auto'
min track sizes behave as 'min(max)-content' when sizing under
a min(max)-content constraint" then the current text looks correct.
If so, I think it would be equivalent to stating upfront that "if sizing under
a min(max)-content constraint then treat an 'auto' min track sizing
as a 'min(max)-content' track min sizing in the following rules"
(for any span).
fantasai commentedon Sep 21, 2016
I don't think there's an intentional difference... what is the difference you're noticing?
MatsPalmgren commentedon Sep 25, 2016
I don't think I can explain it better than I did in the last comment.
Anyway, the problem I originally reported doesn't exist so I'm fine with
the current spec text in that regard.
MatsPalmgren commentedon Sep 25, 2016
You might want to fix the editorial issue with the labels I mentioned above though...
fantasai commentedon Feb 2, 2017
Tab and I looked over this again and decided to handle it as you suggested in #500 (comment) ... in particular as 2.2 seems to have left out max-content constraint handling for
auto, even thoughmax-contentis handled there, and that seems like an error.[css-grid] Define min/max-content constraint handling of 'auto' for s…
fantasai commentedon Feb 2, 2017
Fixed in d8a33b9 . Please let us know if this seems correct now. :)