User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b3) Gecko/20091115 Firefox/3.6b3
FF's css width, min-width, max-width, height, min-height, and max-height properties do not work correctly using percentages % values on two or more -moz-box flex elements. The following is an example where the center and right column elements do not correctly calculate the widths in firefox 3.6.3 beta. In the Safari 4+ browsers, it does calculate and display them correctly in the attached example. Presently, there is no work around to correct it. Height has the same problem with two or more -moz-box-orient: vertical elements too. Please, it will need to be fixed. Hopefully, sooner than later. Who ever fixes this, and lives or visits NYC will get a free dirty water dog on me. Thanks.
Steps to Reproduce:
1. Paste example code from additional information into a HTLM file.
2. Save file to your local drive.
3. Open file in a FireFox 3.6.3 beta browser.
The first column is set to a shrink to fix column width, and works as expected. The second and third columns set at 50% width, do not working as expected. The second column is extremely stretch, and the third column is extremely crunched.
The first column should shrink to fix the width of it's content. The second and third columns set at 50% width, should split the remaining space as expected. A correct expected rendering of it, can be viewed in any safari 4+ browser.
<html class="boxsizeBrd HtWd100pcMaPaBd0">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Example: Equal Height Columns with CSS Flexible Box Layout</title>
border: 1px #666666 solid;
<body class="boxsizeBrd HtWd100pcMaPaBd0" style="background:white;">
<div class="container boxsizeBrd boxDisplay hBoxOrient boxalignStretch" style="background:blue; height:auto; width:80%;margin:0px auto">
<div class="childContainer boxsizeBrd blockDisplay boxFlex0" style=" width:auto; min-width:auto; white-space:normal;">Left-hand-column</div>
<div class="childContainer boxsizeBrd blockDisplay boxFlex1" style="width:50%; min-width:50%; white-space:normal;">
Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World Hello World
<div class="childContainer boxsizeBrd blockDisplay boxFlex1" style="width:50%; min-width:50%; white-space:normal;">Right-hand-column</div>
It looks indeed strange especially with Firefox 3.6 and trunk. Every browser has its own idea how it should be displayed. Opera for instance places the three columns vertically.
Created attachment 413391 [details]
To my best, Opera has yet added http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/#flex support to any of it's public builds. So I did not include the code for the example to work with Opera. Although Opera is not currently supporting it, I did update the example for future testing of Opera. If it's needed, I can provide a link to it at my website at www.zoshe.com or add it to a comment here.
I believe Browsers should fit-to-width first, than fit-to-max-width or fit-to-min-width second, and than fit-to-flex third. Same for height too. Safari is clearly following this logic, and so does Firefox when the min-width is set with a unit size other than %. For example, FireFox follows this logic when the second and third columns min-width is changed from min-width:50% to min-width:25em . Currently, I have not tested all the unit sizes, but they all should follow this logic. Presently, I have tested the following unit sizes:
px - works as expected.
em - works as expected.
% - does not work as expected.
This fails in Firefox 3.5.5 (MacOS 10.5) and 3.6b3pre (Win 7) and IE 8.0.7600 (Win 7)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:188.8.131.52) Gecko/20091102 Firefox/3.5.5
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b3pre) Gecko/20091110 Namoroka/3.6b3pre
Works correctly in Safari (MacOS 10.5)
Version 4.0.3 (5531.9)
IE fails the most - The columns are spaced vertically rather than horizontally. Sounds like what Ria said Opera looks like. For FFx 3.5.5 and 3.6pre, columns are spaced horizontally, but not correctly sized as described in comment #0.
Ria- Anything else you wanted tested since you added qawanted? Removing it for now.
Created attachment 413739 [details]
Firefox 3.5.5 snapshot - Fail
Created attachment 413740 [details]
Firefox 3.6 Snapshot - Fail
Created attachment 413741 [details]
IE 8 Snapshot - Fail
Created attachment 413744 [details]
Safari 4 Snapshot - Pass
Submitted 4 snapshots for easy reference.
IE like opera currently do not support the flex box model. But the recent showings of the upcoming IE9 version does make me strongly believe, it will in the future release of ie9. I did not add any opera(-o-) or ie(-ms-) vendor extensions to the example code, because neither have officially announced any for the flex box layout model. Therefor, both ie and opera will not correctly show what is expected in the test case example. Also, I notice Opera does not always exclusively use "-o-" for a vendor extension. For some css properties, Opera does use -xv- . Highly unlikely, but maybe Opera has these properties working under a different -??- extension.
(In reply to comment #7)
> Created an attachment (id=413741) [details]
> IE 8 Snapshot - Fail
Created attachment 460618 [details]
I updated the testcase file so it can also include Internet Explorer, KHTML, and the Opera browsers.
Created attachment 485559 [details]
Chrome 5 Snapshot - Pass
Created attachment 485560 [details]
Opera 10.63 Snapshot - Fail
ref: https://bugzilla.mozilla.org/show_bug.cgi?id=394078 for XUL bug
Is this still a problem for the modern implementation of flexbox?
(In reply to Gordon P. Hemsley [:gphemsley] from comment #14)
> Is this still a problem for the modern implementation of flexbox?
Tested it with FF22 released today, still buggy
(In reply to Veeck from comment #15)
> (In reply to Gordon P. Hemsley [:gphemsley] from comment #14)
> > Is this still a problem for the modern implementation of flexbox?
> Tested it with FF22 released today, still buggy
to be clear, the "modern implementation of flexbox" uses all-new keywords (display:flex, etc), so it would require a different testcase to test it. It looks like comment 15 was just re-testing the existing testcase, in current builds.
(Aside: there's no reason to suspect that this bug *would* affect the modern implementation of flexbox, since it's a completely separate implementation under-the-hood, with its own new and different (and hopefully few ;)) bugs.)
Anyway -- I don't believe this affects modern flexbox -- we have several automated testcases that check that percentage flex-basis values work correctly, in this file:
...which means percentage width/height values should also work (since flex-basis:auto just proxies through to width/height).
In the unlikely event that something like this *does* affect modern flexbox, we should track that in its own bug.
Created attachment 807998 [details]
testcase new syntax
– updated to current flexbox spec (ignoring tweener syntax in IE 10, IE 11 will have the new syntax)
– removed unused style definitions
– removed prefixes (except -webkit- due to high number of implementations that still use this)
– other cleanup
I simply converted the properties 1:1 from old to new syntax. The result does not look like the way it should compared to the screenshots provided. However, both Firefox and Chrome render about the same so this may actually be the intended behaviour (I did not check what the spec says).
Comment on attachment 807998 [details]
testcase new syntax
Per comment 16, this bug is about "-moz-box".
The new flexbox implementation and layout model are completely different (though the spec is related), so it makes sense that broken -moz-box testcase would still be broken after *just* a keyword switchover.
Given that firefox and chrome agree on this testcase, I'm assuming it's correct (though that doesn't really say anything about this bug, since this is a bug in our display:-moz-box implementation, not in our display:flex implementation.)