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
Component: General → Layout
OS: Mac OS X → All
QA Contact: general → layout
Version: unspecified → Trunk
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
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/
-moz-box elements shrink-wrap by default, just like table cells, floats, etc. Why is this a bug, exactly?
@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.
> @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.
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
> 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.
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/).
> -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...
Are bugs from the old spec still relevant?
You need to log in before you can comment on or make changes to this bug.