Nested Flexbox elements not shrinking

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
3 years ago
2 years ago

People

(Reporter: tiago.f.a.correia, Unassigned)

Tracking

(Blocks 1 bug, {testcase})

34 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Reporter

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160205155049

Steps to reproduce:

1. Have a fixed width div inside 4 nested flexboxes.
2. The flexboxes have alternating layout orientations: vertical -> horizontal -> vertical -> horizontal
3. Shrink the window's width


Actual results:

The two inner flexboxes don't shrink accordingly.
I have made a small HTML page to show the problem. See attached: NOT_WORKING_flex_box_resizing_four_nests


Expected results:

The two inner flexboxes should shrink accordingly
Reporter

Comment 2

3 years ago
If the fixed width div is contained within only two nested flexboxes, then it works fine (see WORKING_flex_box_resizing_two_nests.html)

In addition:
* Chrome also suffers from the same issue.
* IE works as expected.

Updated

3 years ago
Component: Untriaged → Layout
Keywords: testcase
Product: Firefox → Core

Updated

3 years ago
Blocks: 984711
Version: 44 Branch → 34 Branch
I believe this is things working as expected. Your "NOT_WORKING" testcase should work (in Chrome and Firefox) if you add "min-width: 0" to the horizontal flex items (each element whose parent is a horizontal flex container).

Flex items have a minimum "main-size" (min-width if they're in a horizontal container, min-height if they're in a vertical container) which is basically the width of their contents.  They won't shrink below that size, despite "flex-shrink:1", unless you clear it by setting "min-width" to something else.  This is specced in more detail here:
 https://drafts.csswg.org/css-flexbox-1/#min-size-auto
Blocks: minsizeauto-fallout
No longer blocks: 984711
I just added this, to remove the flexbox default "implied minimum width" behavior on the children of your horizontal flex containers:
      [layout][horizontal] > * {
        min-width: 0;
      }
...and that makes your NOT_WORKING testcase work.
(Also: your "WORKING" testcase only works because it only has a single element which is a flex item in a horizontal flex container -- the black div itself. So that black div is the only div that's getting the "implied minimum width" behavior.)

Hopefully this clears things up. Thanks for taking the time to file a bug, in any case!

[Resolving as INVALID since this is us doing what the spec calls for]
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
Reporter

Comment 6

3 years ago
You are right, adding min-width:0 makes it work.

Still it sounds like the default value should have this behaviour.
min-width:0 used to be the default value; the reason that flexbox added this new magic "auto" value is a bit involved, more than I can get into in a bug comment.

Basically, the CSS working group decided that "flex-shrink:1" was a useful default behavior (so that things can shrink for smaller screens, even if authors didn't test that).  But if we let stuff shrink arbitrarily, then flex items will overflow. So, the compromise behavior is: by default, let flex items shrink (in the flex container's main axis), but only down to the item's min-content size.

It's a bit more complex than this (see the spec), but that's the basic idea. (And yes, it still causes surprise/confusion sometimes. :-/  The working group didn't have a better option available to them.)

Comment 8

2 years ago
Pushed by bhearsum@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/aaf1a83844cf
improve release automation publishing of releases - allow pushes to be scheduled instead of done directly. r=rail

Comment 9

2 years ago
Pulsebot is drunk. :D
No, the push just had the wrong bug # in the commit message (should have been bug 1347212).
You need to log in before you can comment on or make changes to this bug.