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
the box element appears as an inline-block box
the box element should appear as a block-level box
adding a width value changes the display to a block-level box
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:
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
-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.”
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
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
However, your emails in that thread
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
> 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
-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?