Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 507397 Flex container width and height incorrectly calculated for `flex-flow: column wrap`
Starred by 30 users Reported by philipwalton@google.com, Jul 6 2015 Back to list
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocking:
issue 588469



Sign in to add a comment
Chrome Version       : 45.0.2449.0 (Official Build) canary (64-bit)
URLs (if applicable) : http://codepen.io/anon/pen/pJLwYp
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
    Safari 8: FAIL
    Firefox 41: FAIL
    IE 7/8/9/10: FAIL
    Edge: OK

What steps will reproduce the problem?
1. Go to http://codepen.io/anon/pen/pJLwYp
2. Notice how the containing <ul> does not actually contain it's <li> children. It's size is being incorrectly calculated.

What is the expected result?

The <il> children should be contained no matter how they wrap and no matter how many children are present.
If you look at the demo in Edge, it renders correctly.


What happens instead?

The containing <ul> does not fully contain its children.


Please provide any additional information below. Attach a screenshot if
possible.

 
Screen Shot 2015-07-06 at 1.10.38 PM.png
515 KB View Download
Labels: OS-All M-45
Status: Untriaged
Tested on Windows 7, Ubuntu 14.04 and Mac OS 10.10.4 using chrome - 45.0.2449.0 version by following steps mentioned below.

1. Navigated to http://codepen.io/anon/pen/pJLwYp
2. Observed that only one and two child is calculated

Tested the same on chrome older versions M35 - 35.0.1905.0 and observed the different behavior as seen in the screenshot.Nowhere I couldn't see the <ul> fully contains its children.

This is a non-regression issue,Hence marking it as untriaged.
Thanks!

version 35.0.1905.0.JPG
87.5 KB View Download
Cc: mbollu@chromium.org
Labels: Cr-Blink-CSS
Comment 4 by tkent@chromium.org, Jul 9 2015
Labels: -Cr-Blink-CSS Cr-Blink-Layout-Flexbox
Comment 5 by e...@chromium.org, Aug 27 2015
Owner: cbiesin...@chromium.org
Status: Assigned
So bug 525051 fixed the vertical part of this sizing problem. Haven't looked into the horizontal part yet.
Cc: dholb...@gmail.com
Interestingly we match Firefox as far as calculating the width goes. However I think Edge is correct here, not us:
"The min-content cross size and max-content cross size of a flex container are the cross size of the flex container after performing layout into the given available main-axis space and infinite available cross-axis space."
https://drafts.csswg.org/css-flexbox/#intrinsic-sizes

So this seems to imply that we do need to take the max-height into account for this computation (right?)
Comment 8 by dholb...@gmail.com, Oct 9 2015
Yup, I think Firefox is wrong here -- this sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=995020
Issue 538927 has been merged into this issue.
Issue 562361 has been merged into this issue.
Labels: allpublic
Labels: -Pri-2 Pri-3
https://lists.w3.org/Archives/Public/www-style/2015Dec/0114.html

So we're matching the spec right now, afaict. And doing anything else is not really possible, because it makes preferred width calculations depend on layout :(

Lowering priority because we're doing what we can.
Comment 14 by msten...@opera.com, Dec 16 2015
Cc: msten...@opera.com
Passes in Presto too (for those (like me) who cannot run Edge). :)

I guess we "simply" have to make LayoutFlexibleBox::computeIntrinsicLogicalWidths() flex line aware?
So, we can't, at least not for column flexboxes, because that would require knowing the *height* of each flex item. And that requires layout.
Comment 16 by msten...@opera.com, Dec 17 2015
Right now we can't.

To avoid requiring layout, we could get the engine to calculate a hypothetical logical top and height that an object would get if maximum preferred width become the width we actually end up using. That will help us figure out which item goes on which line. I talked briefly about this hypothetical top/height here:

https://groups.google.com/a/chromium.org/d/msg/layout-dev/M8Zs92fiA08/COR3DyXBDAAJ

This is what is done in Presto, and it should improve the situation by quite a lot, if done in Blink too.

Am I right in assuming that the item widths (i.e. cross sizes in the test case) aren't affected by the flex container's width when flex-flow is "column wrap"? The spec seems to suggest this, and all browsers but Presto seem to follow it. Presto allows shrinking of the lines' cross size (i.e. width) if the flex container isn't wide enough.

Try this and make the window narrow:

<div style="display:flex; flex-flow:column wrap; height:70px;">
    <div style="height:30px;">Item 1. This text should never break.</div>
    <div style="height:30px;">Item 2. This text should never break.</div>
    <div style="height:30px;">Item 3. This text should never break.</div>
    <div style="height:30px;">Item 4. This text should never break.</div>
</div>

Tested IE, Blink, Gecko and Presto.
Only Presto will wrap the text if the flex container isn't wide enough. I hope this is a bug, or otherwise calculating preferred min/max widths will be a nightmare (probably impossible to calculate, when I think about it). BTW: If it's true that cross sizes don't depend on the flex container size in a multi-line (flex-wrap:wrap) situation, it means that minimum preferred width will always be the same as maximum preferred width in the "flex-flow:column wrap" case.
Comment 17 by msten...@opera.com, Dec 17 2015
Cc: -mbollu@chromium.org
-mbollu@chromium.org - mails bounce.
If this issue is not fixed, then "flex-flow: column wrap" is useless. And if something is useless just because it follows some spec, then the spec is wrong.
Cc: fanta...@gmail.com tabatkins@chromium.org
Only useless for inline-flex or otherwise shrinkwrapped flexboxes.

Anyway, the spec now has wording that makes this work as you expect. However, it can't be implemented in Blink because it requires doing layout during preferred width calculation, afaict. Though I don't really understand parts of the text.

https://drafts.csswg.org/css-flexbox/#intrinsic-cross-sizes
Blocking: 588469
Cc: domenic@chromium.org
In some instances, you may be able to workaround this issue by using vertical writing mode.

That is, instead of using "flex-direction: column;", use "flex-direction: row; writing-mode: vertical-lr;". Remember to reset to "writing-mode: initial;" in the children of the flexbox.

Came up with this in a discussion with domenic (thank you!)
#21 - Unfortunately that doesn't work in FF so we'll need webdevs to set the explicit expected rows/columns widths/heights. Just an FYI.
Comment 23 by fanta...@gmail.com, May 16 2016
That's a silly workaround and I would prefer if webdevs didn't have to mess with writing-mode to make this work. If someone is messing with writing-mode like that, it may as well be Blink-internal code.
Project Member Comment 24 by sheriffbot@chromium.org, Jun 14 2016
Labels: Hotlist-Google
Cc: cbiesin...@chromium.org ranjitkan@chromium.org harpreet...@samsung.com esprehn@chromium.org tony@chromium.org ojan@chromium.org
Issue 407354 has been merged into this issue.
Issue 631155 has been merged into this issue.
Labels: Hotlist-Interop
Some discussion: https://twitter.com/xzyfer/status/829877869354446848
Issue 696785 has been merged into this issue.
Cc: -ojan@chromium.org
Sign in to add a comment