635182 - Improper top-margin added when element with "display: -moz-box" contains empty element

Status: NEW

(Core :: Layout: Block and Inline, defect)

Description

[Simon]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

When working with "Display: -moz-box" some strange behavior occurs. The problem is self-explaining. See the attached files.

Reproducible: Always

Steps to Reproduce:
1. Run the test file or watch the screenshots
2. Compare the right box to the left box
Actual Results:  
The left demo shows some improper top margin above the second inner box. The right demo displays it perfectly. The only difference is, that the left demo contains an empty div (<div></div>) where as the right demo contains a text node in its second inner div (<div>&nbsp;</div>).

Expected Results:  
No matter if the second inner div-element is empty or not, the results should look the same and no improper margin should be added.

Bug present in FF 3.6.x and 4.0bX.
Works perfectly in Chrome 9+.

Comment 1

[Simon]

Attachment: Picture of the error in Firefox 4b11

Comment 2

[Simon]

Attachment: Picture how it works perfectly in Google Chrome

Comment 3

[Simon]

Attachment: Test case to demonstrate the bug

Comment 4

[Ed Morley [:emorley]]

Confirmed using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre ID:20110217123853

Comment 5

[Boris Zbarsky [:bzbarsky]]

This is expected behavior if the baseline of an empty box is at the top edge of the box (which it is in Gecko), given the rest of the styling and markup in the testcase.  Note that the current flexbox draft does not define where the baseline of a box falls, by the way, so both behaviors are correct per the draft.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Tab, once you recall what it was you guys decided at the face-to-face, please do let me know, ok?

Comment 7

[Simon]

Well, although this might be the correct behavior, from my point of view as a developer I really prefere they way Chrome does it! It is not nice if a box jumps around when I use javascript to add content.
So, the question I have is: Will this be fixed or will it say they way it is now?

Comment 8

[Tab Atkins Jr.]

Found it.  We resolved in Oslo that the baseline of a flexbox is the baseline of its first child, just like an inline-table.

Do we need some additional wording to handle empty flexbox children, or is the baseline of empty boxes already sufficiently defined?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> It is not nice if a box jumps around when I use javascript to add content.

Well, you can change the styling to avoid that (e.g. setting vertical-align on the box).

You want that anyway, because otherwise it might "jump around" depending on how the baseline and ascent of the content you add compares to the default baseline and ascent of the block the box is in.

> We resolved in Oslo that the baseline of a flexbox is the baseline of its
> first child

Well, sure.  That's not the issue here.

> is the baseline of empty boxes already sufficiently defined?

It's defined on a case-by-case basis.  For example, the baseline of an empty inline-block is different from the baseline of an empty table-cell, and both are explicitly specified in CSS2.1 (sections 10.8.1 and 17.5.3 respectively).

Comment 10

[Boris Zbarsky [:bzbarsky]]

There's a separate issue here, btw, which is that we do baseline-alignment of non-inline boxes at all.  Webkit does not do that.  We should be treating them as block-level in blockframe, perhaps.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase showing inline boxes (note webkit is still doing weird stuff with the empty box)

Comment 12

[Tab Atkins Jr.]

(In reply to comment #9)
> > is the baseline of empty boxes already sufficiently defined?
> 
> It's defined on a case-by-case basis.  For example, the baseline of an empty
> inline-block is different from the baseline of an empty table-cell, and both
> are explicitly specified in CSS2.1 (sections 10.8.1 and 17.5.3 respectively).

Flexbox children aren't special in any way - the only requirement is that they're block-level.  The baseline, then, should be defined by the layout mode of the child.

(I just noticed that a flexbox with no children doesn't have a defined baseline - that does indeed need to be defined.)

Comment 13

[Boris Zbarsky [:bzbarsky]]

> (I just noticed that a flexbox with no children doesn't have a defined baseline

Yes, that's the case I was talking about, and the case that the testcases are about.  What were _you_ talking about? ;)

Comment 14

[Tab Atkins Jr.]

I didn't pay sufficient attention to the testcases!

I now understand what is actually being asked, and have put a query up on the CSSWG list.  I've poked AlexMog to weigh in on the issue.

Comment 15

[Simon]

Just another thing I would like to add: When I use a fixed number for "height" of the inner div and drop the flex box stuff, Firefox aligns the inner div properly at the top, without any margin on top of it. This works in both scenarios. I would argue that "display: -moz-box" should behave similar. Not having a child IN the box should not affect its OUTer position. I would suggest to specify any default behavior to reflect this. However I am not an expert on the flex-box model so there might be good reasons why it behaves the way it does, but from a developer's point of view it just looks more like a bug than a feature.

Comment 16

[Simon]

Attachment: The solution that was proposed Boris Zbarsky in action

Comment 17

[Boris Zbarsky [:bzbarsky]]

Simon, fox -moz-box, I agree; see comment 10.  But for inline-box, kids absolutely would affect the "outer" position, just like the do for inline-block...  If there are no kids you can't put the baseline at the kids' baseline, because the concept doesn't make sense.

Comment 18

[Simon]

I see what your saying: for inline-boxes this behavior is wanted, but for regular block-boxes, like in my case, the bahavior will be changed/fixed, right?

Comment 19

[Boris Zbarsky [:bzbarsky]]

Yes.