Repository navigation
[css-grid] Resolving percentage heights of grid items during min-content sizing #2674
Description
When a grid item
- is found inside a container whose track is
mimax(min-content, 1fr)or1fr - has
height:100%
How do you compute the min-content height of the track?
- Usually in CSS we ignored
height:100%asheight:auto - However sometimes we resolve to
height:0during that phase
(for instance see table cells children havingoverflow:scroll)
https://wptest.center/#/gawww8 (replaced element)
https://wptest.center/#/v298y2 (in wrapper)
https://wptest.center/#/18osz0 (in wrapper with overflow)
Currently:
- Edge does
autoautoauto - Chrome/Firefox do
0autoauto - My feeling is we should all do
autoauto0
Is some behavior defined in the spec? Is it the behavior we want?
Activity
[-][css-grid] Resolving percentages[/-][+][css-grid] Resolving percentage heights of grid items during min-content sizing[/+]fantasai commentedon May 17, 2018
OK, so, I think you're missing a few things.
auto, notmin-contentas the min track sizing function. You're right that the min track sizing function should resolve to zero in that case:overflowis notvisible(orclip), and thus the automatic minimum size doesn't apply.So the base sizes of the tracks should be
0auto0. :) And the behavior of 1fr rows and 1fr columns should be symmetric.tabatkins commentedon May 17, 2018
Agreed,
0auto0are the correct answers per spec. All browsers are a little wrong. ^_^tabatkins commentedon May 17, 2018
@MatsPalmgren @mrego @javifernandez Do y'all agree with the above? If so, we need to file bugs on all the browsers.
MatsPalmgren commentedon May 17, 2018
@fantasai that statement makes no sense. Base sizes are the result from the Track Sizing Algorithm - they can't be "auto". They are always a definite size. I'm assuming you mean "the block-size of the grid item after it is flowed in a containing block (CB) that has an inline size of 200px". So, I assume you mean "0 ~200px 0".
Also, I don't understand why you think the base size should be zero in the third test. You are correct that Automatic Minimum Size doesn't apply, but that doesn't make the min-content contribution zero - it's still "the block-size after flowing it", which in this case is 204px (the CB inline size is definite (200px), which makes the
<figure>width 200px which provides a CB inline size for the image which becomes 200px in height, which makes the<figure>grid item have block-size 204px in Nightly because the<figure>(a block) baseline adds 4px (addingvertical-align:topmakes it 200px). I can't find any spec that says thatoverflow != visible(and a block-size that "behaves as auto") on non-replaced blocks implies they have zero min-content size. Please point it out if I missed it, thanks.FremyCompany commentedon May 18, 2018
Also, I'm still a bit confused. If the rule that makes the image be 0px tall is in css-sizing, why doesn't the same happen inside a flexbox?
In both case the flexbox is size vertically as the image.
Is that because it uses max-content and not min-content?
Even so, I'm still a bit perplexed by
Why doesn't the image stop at 21px, that seems to be a stricter constraint than its max-content contribution, it does act like if 32px was its min-content contribution here, am I missing something?
fantasai commentedon May 19, 2018
@MatsPalmgren Yes, that's what I meant.
Right, but we're not looking at the min-content contribution when we're calculating the base size.
1frexpands tominmax(auto, 1fr), notminmax(min-content, 1fr). The grid container is not being sized under a min/max-content constraint--it's explicitly sized at 300px. So theautominimum is supposed to mean “use the automatic minimum size”, which due to theoverflowsetting is zero in this case. https://www.w3.org/TR/2017/CR-css-grid-1-20171214/#algo-single-span-items It seems that this is working fine in browsers when calculating columns, it's just not happening for rows. (Note the ED has some half-baked edits on this section, so linking to the CR.)The point of
autois to add some automagic to the minimum (primarily to account foroverflow), so that it is not always the min-content size--if we simply used the min-content size here always, we'd be defeating the point.@FremyCompany Yes, in those first two cases, your flex container has an auto height, so it first calculates the container size from the max-content contribution of the items, then it resolves the percentage against that. In this case, the max-content contribution of the image is larger than the text, and is controlling the size of the container. Resolving 100% against that means the image simply is the size it is.
In the third case, the float's size is resolved as clamp(min-content, CB, max-content). The min-content size of the image is zero, the max-content is 32px, and CB is 9px, so we get 9px for the float, and the image's 100% width resolves against that.
In the last case, the percentage is attempting to resolve against an indefinite size (because while the max-height is definite, the height is not). And such percentages do not resolve; the percentage height is thrown out and treated as the initial value,
auto. Meanwhile the width resolves against the float's width, which is clamp(min-content, CB, max-content) = max-content of the image = 32px.MatsPalmgren commentedon May 19, 2018
Right, I'm aware we're in the "
heightthat behaves as auto" part of min-size contribution. Note that it says "computed min-width or min-height value" though. The computedmin-heightvalue isautoso it says we should return the outer size forheight:autowhich is the flowed block-size. I'm guessing you meant "used min-width or min-height value", because then there is now a clause in AMS that says "the automatic minimum size is otherwise zero, as usual" in the current draft (it was previously undefined). Then you would get the desired "outer size withheight:0" result in the third test.I agree with the results you suggest for the testcases and I've filed a bug to fix the layout for the third testcase in Gecko.
FremyCompany commentedon May 19, 2018
Alright, thanks for helping clear that up!
MatsPalmgren commentedon May 19, 2018
min-size contribution says "... as its specified size (
widthorheight, whichever matches the relevant axis) ...". Did you mean to use the term preferred size rather than "specified size" here?Also, I'm still not sure how min-size contribution results in a row base size of zero in the first grid test above.
Here's a somewhat simplified example: https://wptest.center/#/9tgtf3
The image
heightbehaves as auto when calculating its min-size contribution in the block axis so the resulting min-size contribution is theouter sizeafter replacingheightwith used value ofmin-height.min-heightisauto, thus AMS applies. There is no "specified size suggestion" (sinceheightbehaves as auto). The transferred size is 10px (width:10pxtransferred through a 1:1 ratio). Thus the min-size contribution is 10px, which makes the row size 10px. The final image size is then 10px x 20px sinceheight:200%resolves to 2 * the row size during layout.I don't see anything that would suggest that the second bullet in Percentage Sizing would apply in this case, since that rule is specifically restricted to "when calculating the min-content contribution". I don't think we're calculating a min-content contribution under the transferred size suggestion. If you want image grid items with a percentage preferred size to contribute zero to the track base size then I think you need to include min-size contribution too. Something like "when calculating a min-content or min-size contribution".
14 remaining items
css-meeting-bot commentedon Mar 13, 2019
The CSS Working Group just discussed
Resolving percentage heights of grid items during min-content sizing (review last fix), and agreed to the following:RESOLVED: Make the same result for min content sizing apply to automatic minimumsThe full IRC log of that discussion
<dael> Topic: Resolving percentage heights of grid items during min-content sizing (review last fix)<dael> github: https://github.com//issues/2674#issuecomment-465490328
<fantasai> https://github.com/w3c/csswg-drafts/commit/534f79283a4687a5f0bc722baed5792e2c54433a
<dael> fantasai: There's some sizing rules where we decided percentages resolve to 0 something depending on when you're tacking intrinisic sizes. Clarifies the 0 basis also applies for automatic min size so that it ends up being definite
<dael> fantasai: Automatic min size is a derivation of min content sizing so this is saying same rules for min-content sizing apply to automatic minimum
<dael> astearns: Reasonable to me
<dael> astearns: Other comments or concerns?
<dael> astearns: Objections to make the same result for min content sizing apply to automatic minimums
<dael> RESOLVED: Make the same result for min content sizing apply to automatic minimums
Bug 1462854 part 2 - [css-grid] Handle [max-]width/height percentages…
Bug 1462854 part 2 - [css-grid] Handle [max-]width/height percentages…
Bug 1462854 part 2 - [css-grid] Handle [max-]width/height percentages…
Bug 1462854 part 2 - [css-grid] Handle [max-]width/height percentages…