625694 - Flexbox display:box treated as display:inline-box if there’s no width

Status: UNCONFIRMED

(Core :: Layout, defect)

Description

[Oli Studholme]

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

Comment 1

[Oli Studholme]

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

[Ryan Fioravanti]

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

[Boris Zbarsky [:bzbarsky]]

-moz-box elements shrink-wrap by default, just like table cells, floats, etc.  Why is this a bug, exactly?

Comment 4

[Oli Studholme]

@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

[Boris Zbarsky [:bzbarsky]]

> @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.

Comment 6

[Oli Studholme]

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

[Boris Zbarsky [:bzbarsky]]

> 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

[Thomas Bielagk]

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

[Boris Zbarsky [:bzbarsky]]

> -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

[sjw]

Are bugs from the old spec still relevant?