Flex Items Grow too Wide with flex-direction:row

[jpdevries]

Top: Safari (correct) Bottom: Firefox (incorrect)

So in this codepen we have a flex parent (.eureka) with two children .pathbrowser (blue) and .stage (green).

The .stage is also a flex parent that uses flex-direction:column to lay it's two children (.topbar and .eureka-table) out vertically.

The .eureka-table contains a basic table that a has a tbody that uses overflow-x:auto for scrollbars with a bunch of content in it.

The concept of the layout is the blue sidebar on the left takes up a fixed amount of space while the stage takes up the rest. The stage should be able to overflow content without breaking the layout.

Currently In Firefox 38 and Edge nightly the content does not overflow correctly and the layout breaks.

This codepen forks the above codepen and makes one change (line 34) that sets .eureka {flex-direction:column}. This will make the blue sidebar layout incorrectly but notice the table content now overflows correctly.

Also see #42

[jpdevries]

Here is a simplified pen that also shows the issue. View in Firefox/Edge vs Chrome/Safari to see the difference http://codepen.io/jpdevries/pen/mJROOL

It's probably worth noting that the concept of the layout is the blue sidebar is fixed with the overflowing content on the right takes up the remaining space. If this is switched and the stage area uses a set width (like a percentage or something) the layout can be achieved cross browser, but that isn't an acceptable solution.

[jpdevries]

Here is another pen with a kinda nasty work around. It uses a wrapper div around the .block elements and position:absolute to get the desired layout to work. It also requires setting a height on the component (as the overflowing content is within an absolutely positioned container).
So it's not real an ideal solution but might help further demonstrate the issue. The .stage container should not keep growing, but it does in Firefox and IE hints the need for position:absolute
http://codepen.io/jpdevries/pen/GJrNxY

[philipwalton]

Chrome Canary renders your second example the same as FF/Edge, which makes me think this is just Flexbug 1. Can you check and make sure?

Also, fwiw, when you use bourbon in your demos its harder for me to figure out what's going on.

[jpdevries]

@philipwalton thanks for having a look. I forked the second pen again and removed bourbon
http://codepen.io/anon/pen/EjZwNy

Without the vendor prefixes it won't work in certain browsers of course.

I'm seeing what you mentioned, Canary is rendering that pen the same as FF/Edge 😲

I guess what I don't understand is how are you supposed to tell the .stage to not make it's parent keep growing?

In #42 which seems related the answer I came up with was to use flex-basis:0 or flex-basis:0% but that doesn't work here 😢

[jpdevries]

Well, this is almost promising. I created another pen with yet another work around. This one uses a .stage-inner wrapper with these styles

.stage-inner {
  display:flex;
  flex-direction:column;
  flex-grow:1;
  flex-shrink:1;
  flex-basis:100%;
}

seems to works in Canary, Chrome, Safari but not FF/Edge.

Theres a $prefix on line 3 that will output prefixes if true.

[philipwalton]

Without the vendor prefixes it won't work in certain browsers of course.

I use autoprefixer on all the Flexbug demos. It allows you to write valid CSS, and it adds all the necessary prefixes behind the scenes.

I guess what I don't understand is how are you supposed to tell the .stage to not make it's parent keep growing?

If you give the parent an explicit width or max-width, it will not grow larger than that.

I don't think there's an actual bug here that's not already documented in the README. If I've missed something, feel free to comment or reopen.

[jpdevries]

@philipwalton I feel this should be re-opened or discussed further. I'm also not sure which section of the README you feel covers this issue. Did you see what I mentioned above?

It's probably worth noting that the concept of the layout is the blue sidebar is fixed with the overflowing content on the right takes up the remaining space. If this is switched and the stage area uses a set width (like a percentage or something) the layout can be achieved cross browser, but that isn't an acceptable solution.

Isn't the whole point of flexbox to not have manually calculate widths? By the very nature of flexbox you may not know what size it will wind up.

The reason this layout is breaking is a flex item, who is also a flex parent, is growing larger than it should be able to. I've tried my best to understand the flexbox spec, and maybe I am misunderstanding something but are you implying that there is no way to overflow content within nested flex boxes without manually setting width constraints? If so, is that a breaking change from Flexbox 1?

[philipwalton]

@jpdevries I'm honestly not sure what exactly you're reporting in this issue. If your question is just "how do I get this to work cross browser?" then Stack Overflow is probably a better place to ask.

If you're reporting a bug, you should vastly simplify your example, so it can be clearly demonstrated what's not working. Your examples are very involved, and you're doing a lot of strange things with them like using tables but changing their display values to flex. Every level of complexity you add makes it harder for someone else to figure out what's wrong, and it makes it more likely that the problem is really a combination of several factors rather than one specific issue.

The purpose of this repository is to provide people with workarounds to common flexbox bugs, but if we can't isolate exactly what's going on, it's impossible to describe it and warn other people about it.

[jpdevries]

@philipwalton I posted a simplified example that uses divs instead of tables the same day I opened this issue.
#51 (comment)

I also just updated that pen to use autoprefixer so it is more legible.

I think the simplest way to describe the issue would be that a flex item is being allowed to grow infinitely and therefore does not overflow it's own inner content as intended.
With the box model the child affects the parent. With flexbox the parent and siblings affect the child. Right? Well, in this example the issue is that the stage's width should be .page-wrapper width - .sidebar width not keep growing forever.

The purpose of this repository is to provide people with workarounds to common flexbox bugs

I've posted several work arounds and spent a lot of time debugging these issues and done my best to document them. If you feel I've misused this repository I apologize.

[philipwalton]

I posted a simplified example that uses divs instead of tables the same day I opened this issue.

Thanks you. Simplified examples are much easier to reason about.

With the box model the child affects the parent. With flexbox the parent and siblings affect the child.

No, not necessarily. In both models the parent and children can affect each other.

Here's how you can do what you want:
http://codepen.io/anon/pen/GJWgZZ

[jpdevries]

Here's how you can do what you want:
http://codepen.io/anon/pen/GJWgZZ

Dude, you're a magician! Even works in Edge.

It looks like having display:flex on body was messing Firefox, Canary and Edge up.

Thank you so much! This is great 💯

Just For the record

In Firefox Gecko (39) I noticed that simply adding max-width:-moz-available to .page-wrapper also results in the desired layout. This property is experimental of course, and looks like it has only landed in Firefox Gecko so far.

Prior to your helpful response and solution I read the spec and found these sections may be relevant to this discussion:

In the flex layout model, the children of a flex container can be laid out in any direction, and can “flex” their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent. Both horizontal and vertical alignment of the children can be easily manipulated. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions. - Abstract

This both implies that nesting should work (so I'm not sure it breaks with display:flex on body). It also specifies that children of a flex container either grow to fill unused space or shrink to avoid overflowing the parent. In the broken pen note that the body is being overflowed by a child who is a flex container.

The specification describes a CSS box model optimized for user interface design. In the flex layout model, the children of a flex container can be laid out in any direction, and can “flex” their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent. Both horizontal and vertical alignment of the children can be easily manipulated. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions. -

A single-line flex container lays out all of its children in a single line, even if that would cause its contents to overflow. - 6. Flex Lines

This implies that single-line flex containers overflow.

The defining aspect of flex layout is the ability to make the flex items “flex”, altering their width/height to fill the available space in the main dimension. This is done with the flex property. A flex container distributes free space to its items proportional to their flex grow factor, or shrinks them to prevent overflow proportional to their flex shrink factor. - 7. Flexibility

The distributes free space to its items verbiage seems to imply that a group of flex items should not be able to make it's container grow, especially if it's container is also a flex item.

Take into account whether overflow is visible, since when overflow is explicitly handled, it is confusing (and unnecessary) to force enough size to show all the content. - Flexible Box Layout Module

The .stage grows infinitely to force enough size to show all content in my broken pen even though it has overflow:auto if the body has display:flex