421397 - broutek.com site doesn't show properly

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Jose Fandos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre FireShot/0.32
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre FireShot/0.32

Between the menu and the first content there should be 12px gap, but in FF 3.0 it shows an extra gap that is not accounted for. This is not the case in FF 2.0, IE7 or Safari 3.0

Reproducible: Always

Steps to Reproduce:
1. Visit the site in latest FF 3.0 and compare to FF 2.0

Actual Results:  
Extra gaps between the different sections

Expected Results:  
Smaller gaps between the different sections as seen in FF 2.0

Remove the extra gaps that are shown in the latest FF 3.0

Comment 1

[Mariana]

Confirmed, reproducible in Windows XP too.

Comment 2

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031205 Minefield/3.0b5pre ID:2008031205

FWIW the Opera 9.26 rendering is a lot closer to the Firefox 3.0b5pre rendering than it is to the Firefox 2.0.0.13pre rendering.

Comment 3

[Jose Fandos]

Can someone set it to confirmed?

Comment 4

[Peter van der Woude [:Peter6]]

Any ideas Martijn ?

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase in standards mode

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase quirks mode

Comment 7

[Martijn Wargers (dead)]

Well, this regressed when bug 9458 got fixed.
The site in question is using standards mode, I'm wondering why there is a difference in the testcase between standards and quirks mode.

Comment 8

[Martijn Wargers (dead)]

Can someone check whether the look of the site in question regressed at 2007-01-27?
I'm not even sure, if it's the same problem we're talking about.

Comment 9

[Martijn Wargers (dead)]

I guess the extra room in standards mode is because of the line box that is generated. Not really sure how things are exactly supposed to work, though.

Comment 10

[Peter van der Woude [:Peter6]]

Works in 20070125_0340_firefox-3.0a2pre.en-US.win32
Fails in 20070127_1545_firefox-3.0a2pre.en-US.win32

I have no other builds so either nothing else was checked in or the Win32 tree was on fire

Comment 11

[philippe (part-time)]

Note that Opera 9.5b (OS X 10.5.2) renders the Standards Mode test exactly like Gecko. WebKit is different: the --- is within the bordered box.

Comment 12

[Boris Zbarsky [:bzbarsky]]

The inline-block's baseline is the baseline of the last line, looking into nested blocks.  That means, in this case, the baseline of the line with the "---" in it.  Since it's in the line box, and is baseline-aligned, that baseline needs to line up with the baseline of the line box.

Now the top edge of the inline-block is a good ways above that baseline, so the line box has to have at least that much space above its baseline.  So the line box ends up with a nonzero height.

In quirks mode, and in almost standards (which shows the same behavior) you're seeing the quirk for bug 22274, I think. David, is that right?

So it looks to me like the current behavior is correct, and that we should send this over to evangelism.  The only reason it didn't look like this before was because we didn't have inline-block support, so that header div ended up in a block line with a zero height.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Minusing on the assumption that Boris is correct... usually a safe assumption :-)

Comment 14

[Jose Fandos]

So what's the space? It's not clear from the explanation Boris is giving. With Firebug it doesn't show that space as being part of anything and I'm not sure of how to collapse it.

Comment 15

[Boris Zbarsky [:bzbarsky]]

The space happens because the height of a line is the sum of the maximal ascent and the maximal descent of the boxes in that line.  The inline-block's ascent, y default, is the space from the top of the box to the baseline, and the baseline is the baseline of the last line in the inline-block (or of the inline-block's last block child, if the last box in the inline-block is a block).  So in this case the ascent is pretty large and you get the space.  I'm pretty sure the CSS2.1 spec has a pretty picture of how box alignment in a lines works.  Note that the height of the inline-block doesn't directly affect its ascent.

As for collapsing it, you can use "vertical-align: bottom" to help some (at that point the baseline position of the inline-block won't matter).  At that point you'd still have a first line of height at least equal to the line-height of the <body> in that testcase; how you deal with that is up to you, I guess.

Comment 16

[Jose Fandos]

Closing, on the assumption that Boris was correct, and the fact that the site is gone. Not sure what the resolution should be, but going with INVALID.