-
Notifications
You must be signed in to change notification settings - Fork 718
[css-flexbox-1] Inconsistent sizing of replaced elements in flex containers #12012
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 flex item containing text is sized as If you don't want the image to shrink, you can add
It's definite. Automatic size behaving as a definite
That's an entirely different layout algorithm, so of course there are differences. Being more or less predictable is opinion-based. |
Correct, but per CSS2 §10.5:
So This is also shown in Example 11 of CSS Sizing Level 4:
.parent { height: auto; margin: 0; }
.child { height: stretch; margin: 10px; } In the examples provided, the flex container (e.g containing block) has an indefinite height, so |
I agree. What confused me was 9.7(3), which says:
What exactly does that mean? Both items have by default have flex factor of 0 (flex-grow), yet they aren’t frozen. Additionally, the algorithm distinguishes between two situations:
But step 3 gives three freezing conditions:
I understand why the last two conditions don’t apply —but what’s the purpose of the first one—“any item that has a flex factor of zero”? And finally, even if everything is working as spec’d—why doesn’t Firefox reduce the image proportionally, stopping at its intrinsic width, like Chrome does? This feels like a basic behavior that layout engines ought to agree on. |
No, it behaves as auto but doesn't compute to auto (on an element with children you could confirm this using inheritance). CSS2 used the same term for both behaviors, this terminology is now obsolete. See #4525
You already quoted the spec that says you need to use the flex shrink factor here, which is not zero.
The difference is because of the automatic minimum size. I would need to check who is right, but probably Blink, since in Servo we have the same behavior and we tried to follow the spec closely. |
I don't quite follow. According to §3.2.1:
So "behave as auto" is a general term for two things: a) when width/height computes to If But here’s where I’m confused. Take this example: <div style="display: flex; max-width: 500px; font-family: Arial;">
<div>
Lorem ipsum dolor sit amet...
</div>
<img src="box.jpg" alt="box" style="width: 50%; height: auto;" />
</div> The image has So if But from #4525 — and issue #4312 — it sounds like stretching should not occur in the So what does 'behave as auto' actually mean? The current definition suggests an equivalence that doesn't hold up in practice.
I understand that the flex line overflows the container’s main size, so the flex-shrink factor is used. What I don’t understand is the need for the condition 'Any item that has a flex factor of zero'. An item can have a shrink factor >= 1 and a grow factor of 0, or vice versa. But why 'flex factor of 0' is relevant here? In the context of 9.7(3), what actually matters is:
In the example, neither item satisfies the second condition, so we don’t freeze them — makes sense. Why do we need the sentence “Any item that has a flex factor of zero”? Simply put, If we remove that line entirely, would the algorithm’s behavior actually change? |
Anyway, once the flex line height is known, why doesn’t the image's height update to match it in a subsequent layout pass? <div style="display: flex; max-width: 500px; font-family: Arial;">
<div>
Lorem ipsum dolor sit amet consectetur adipisicing elit. Itaque, vitae? Recusandae porro eveniet sapiente placeat magnam enim fugit provident, numquam vero ducimus minus iusto ullam aliquam. Labore, optio? Recusandae nesciunt voluptatem reiciendis deserunt voluptates quod nostrum aperiam ad eius similique explicabo quasi placeat aliquam cumque laboriosam qui animi hic voluptatum, iusto nemo molestiae possimus deleniti dolorum! Quae laboriosam ratione deleniti corporis facere temporibus adipisci, illo doloribus? Maxime sed dicta soluta animi nesciunt saepe eum. Excepturi nam enim numquam ipsam placeat praesentium, optio eligendi natus odit quo sunt nobis quisquam tempora molestias explicabo eveniet est nulla magnam maxime! Optio, maiores temporibus.
</div>
<img src="box.jpg" alt="box" style="width: 50%; height: 100%; font-family: Arial; " />
</div> |
Context:
Consider the following flex layout:
In this case,
flex-basis
is initiallyauto
, which causes it to use thewidth
property. Sincewidth: 0
is specified, that becomes the initial flex base size. However, due tomin-width: 50%
, this base size is adjusted up to the hypothetical main size of250px
. Once the flex item’s main size is resolved, the cross size is determined by laying out the item as if it were an in-flow block-level box. Finally, the cross size is stretched to match the flex line’s used cross size, as expected.Both Chrome and Firefox render the image at
250px
wide. The image's natural size is200x200
.Now consider this modified version:
Here,
width: 50%
is specified directly on the image element. Despite the flex container appearing to have a definite size (considering both the document flow and the constraints imposed by the initial containing block through its ancestors) Chrome seems to disregard the percentagewidth
when computing theflex-basis
, resulting in the image falling back to its natural width of200px
. Firefox behaves differently (though the exact behavior is unclear), but in both browsers, the height is stretched as expected. Interestingly, even when setting the container’swidth: 500px
explicitly (instead ofmax-width
), the outcome remains unchanged, suggesting that the container’s definite inline size state does not play a role in resolving the image’s percentage-based flex base size.Chrome:
Firefox:
Adding
height: 100%
changes things again:This time, neither browser stretches the image to match the full cross size of the flex line. The width behaves similarly to the previous example, but the height stretching now fails.
Chrome:
Firefox:
Compare with an equivalent Grid layout:
Here, both Chrome and Firefox respect
width: 100%
andheight: 100%
, and the image is sized correctly to fill its grid area.Questions:
What parts of the CSS Flexbox specification could explain these discrepancies in sizing behavior, particularly regarding:
Why
width: 50%
is ignored, even when the container appears to have a definite size?If the inline size of the container is not considered definite, could you clarify when the flex container's main size becomes definite in this scenario, and how percentage values like
width: 50%
are handled in this context?Why does the image not stretch when
height:100%
?Why Grid layout appears to handle these same percentage-based dimensions more predictably than Flexbox?
The text was updated successfully, but these errors were encountered: