Open
Bug 625694
Opened 14 years ago
Updated 2 years ago
Flexbox display:box treated as display:inline-box if there’s no width
Categories
(Core :: Layout, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: mozilla.org, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8) Gecko/20100101 Firefox/4.0b8 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8) Gecko/20100101 Firefox/4.0b8 Firefox treats flexible layout boxes with display:box as display:inline-box if the box element doesn’t have a width declared Reproducible: Always Actual Results: the box element appears as an inline-block box Expected Results: the box element should appear as a block-level box adding a width value changes the display to a block-level box
Updated•14 years ago
|
Component: General → Layout
OS: Mac OS X → All
QA Contact: general → layout
Version: unspecified → Trunk
Reporter | ||
Comment 1•14 years ago
|
||
I wrote that “adding a width value changes the display to a block-level box”, but this is incorrect. If the viewport is wide enough display:box flexboxes will display side-by-side. I’ve updated the example page with an example to show this: http://oli.jp/bugs/mozilla/flexbox-display-inline.html
Comment 2•13 years ago
|
||
I have another example of this, you can see if the display:-moz-box element was a block element like it should be then it would be filling the container http://jsfiddle.net/GLex5/2/
Comment 3•13 years ago
|
||
-moz-box elements shrink-wrap by default, just like table cells, floats, etc. Why is this a bug, exactly?
Reporter | ||
Comment 4•13 years ago
|
||
@Boris the spec says: “A box placed in a block is considered a block level element and will be positioned and sized according to the rules for CSS 2.1” “All children of ‘box’ elements are block-level. If inline-level elements are nested inside boxes, they get wrapped in an anonymous block which then takes part in the box layout. If the width of a child of a flexible box is computed as ‘auto’, then the used value is the shrink-to-fit width.” http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/#inlinesAndBlocks I read this to mean that -moz-box *children* elements with width:auto shrink-wrap by default, but that -moz-box elements should display as block level elements. Currently they display as inline-block level elements unless a width is declared.
Comment 5•13 years ago
|
||
> @Boris the spec says: Quoting myself from the thread that mentioned this bug: 1) -moz-box is NOT a prefixed implementation of that draft. In fact, it and its behavior predates that draft by 10 years or so. The only definition of -moz-box is "what Gecko does right now", and things depend on that behavior. 2) That draft is over two years old. There's a more recent version at http://www.w3.org/TR/2011/WD-css3-flexbox-20110322/ which if you will note no longer defines a "box" value for display at all. It also defines behavior that's generally very different from -moz-box; we will almost certainly be writing a completely separate implementation of this flexbox spec that looks nothing like the current XUL box code.
Reporter | ||
Comment 6•13 years ago
|
||
Yep I’m aware of the history of flexbox, and the new flexbox editor’s draft http://oli.jp/2011/css3-flexbox/ However, your emails in that thread http://lists.w3.org/Archives/Public/www-style/2011Jan/0214.html and http://lists.w3.org/Archives/Public/www-style/2011Jan/0228.html gave me the impression that you *would* be fixing -moz-box. Is -moz-box to be mothballed? This would certainly make it easy to resolve this bug in addition to: * https://bugzilla.mozilla.org/show_bug.cgi?id=529761 and https://bugzilla.mozilla.org/show_bug.cgi?id=394078 * https://bugzilla.mozilla.org/show_bug.cgi?id=625697 * https://bugzilla.mozilla.org/show_bug.cgi?id=625700 * https://bugzilla.mozilla.org/show_bug.cgi?id=625703 * https://bugzilla.mozilla.org/show_bug.cgi?id=625702
Comment 7•13 years ago
|
||
> gave me the impression that you *would* be fixing -moz-box.
The plan, last I checked, is to implement the flexbox draft, then slowly transition XUL to the standard flexbox model.
This could be done by suddenly redefining -moz-box to mean the same thing as flexbox (somewhat unlikely, imo), or it could be done by changing the styles in xul.css over to the new box model. We'll see which one breaks fewer things.
Comment 8•13 years ago
|
||
Okay, yeah, I also saw the new draft, but I still don't understand the current situation. -moz-box existed before the draft but has nothing to do with it? It's coincidence that the draft features the same display values and other properties? And also, what is the supposed difference between -moz-box and -moz-inline-box if both don't act like block? I just checked that at least I'm not alone being confused, a lot of articles state that gecko has implemented the draft (e.g. http://hacks.mozilla.org/2010/04/the-css-3-flexible-box-model/).
Comment 9•13 years ago
|
||
> -moz-box existed before the draft but has nothing to do with it? It's > coincidence that the draft features the same display values and other > properties? -moz-box existed before the draft and the draft's text was inspired by (but not really based on) -moz-box. > And also, what is the supposed difference between -moz-box and -moz-inline-box > if both don't act like block? I have no idea. Whatever the observable difference is, that's also the supposed difference. > a lot of articles state that gecko has implemented the draft Yeah, a lot of people are on crack...
Comment 10•11 years ago
|
||
Are bugs from the old spec still relevant?
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•