-
Notifications
You must be signed in to change notification settings - Fork 716
[css-grid][css-flex] Indefiniteness when sizing grid tracks in a flexible flex item #4852
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The core concept of min-width/min-height, per CSS2.1, is that you calculate sizes without it, and then if that constraint is violated, redo the calculation with that value in place of width/height: It seems to be what authors would expect. So I think we should try to keep to that idea, if we can. |
That would mean a behavior change, in practice, for all the layout modes though, as demonstrated by Oriol's second testcase. I think we've strayed away from that original "just rerun layout using this value instead" conception pretty thoroughly. |
@dholbert @cbiesinger Thoughts on this issue? |
This isn't quite whats going on here - it wouldn't involve a change for all layout modes, just a clarification for what should happen with grid. Firefox's behaviour is a little more self consistent just viewing grid layout by itself. Effectively Firefox is applying the "grid rule" that once the "used block-size" is found, we re-compute the grid using that new "used" size in order to re-resolve percents, frs, %-grid-gaps, etc. Normally we don't consider 'auto' tracks when re-computing the grid, as it (typically) doesn't change the result. You can trigger "inconsistency" in Blink's behaviour by added a %-gap or similar to the above testcase. E.g. with a %-gap we behave like Gecko due to recomputing the grid using the "used" block-size. I think I'd be happy to align on Firefox's behaviour here. |
Thinking about this again, I agree with Ian. |
OK, seems like we have consensus in the issue. @Loirooriol Do you have any edits you'd propose to clarify this case? |
I guess I was being confused by the interaction of flex and grid. Let's follow the specs step by step. <div class="wrapper" style="display: inline-flex; flex-flow: column; min-height: 50px;">
<div style="flex-grow: 1; display: grid; background: red">
<div style="font: 20px/1 Ahem; background: green">content</div>
</div>
</div>
So I guess Firefox is already behaving according to the specs, and it's a Chrome bug, and there is no need to edit the specs. |
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: Indefiniteness when sizing grid track inside flex item<fantasai> github: https://github.com//issues/4852 <fantasai> oriol: Case where we don't have interop between FF and Chrome <fantasai> oriol: When have column flex container which has for example height set to some value bigger than the content <fantasai> oriol: This flex item has a flex that causes it to expand <fantasai> oriol: and this flex item is also a grid container <fantasai> oriol: which contains an auto row <fantasai> oriol: usually auto rows, if you have free space at end of track sizing, they are expanded to cover this extra space <fantasai> oriol: specifically for the case where we set the height property, we have interop <fantasai> oriol: but instead of setting height on flex container you set min-height, in Chrome the auto height doesn't grow <fantasai> oriol: At first I was confused and thought Chrome was right, but actually after some feedback from iank_ I think it's actually Firefox which follows the spec <fantasai> oriol: iank_ also said that he's willing to change Chrome to adapt to what FF is doing <fantasai> oriol: So I guess we can close this no change, agreeing that Firefox is the right behavior <fantasai> Rossen_: comments/objections? <fantasai> iank_: ... <fantasai> fantasai: I think authors would be happy with this resolution <fantasai> RESOLVED: close no change, firefox is correct |
Consider this testcase:
In the
min-height
case, the flex container is forced to be at least 50px tall, and then the grid container is also 50px tall due toflex-grow: 1
.But then, how tall should the grid row be? https://drafts.csswg.org/css-grid/#algo-stretch says
It seems to me that the free space is indefinite, since the flex container has
min-height: 200px
instead ofheight: 200px
, so https://drafts.csswg.org/css-flexbox-1/#definite-sizes doesn't applyAnd the grid container doesn't have a definite
min-height
. So the track shouldn't be stretched, and Chromium is right.Something similar happens for block and flex layout. Testcase
However, from https://crbug.com/1055258, some people expect the track to be stretched like in Firefox (and old Edge). So maybe the spec should be tweaked? Or should Firefox just fix their implementation?
Note this is not just for
grid-template-rows: auto
, the behavior is the same forgrid-template-rows: 1fr
. But withgrid-template-rows: 100%
, Chromium stretches the row just like Firefox.The text was updated successfully, but these errors were encountered: