Closed Bug 421397 Opened 13 years ago Closed 7 years ago
.com site doesn't show properly
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
Confirmed, reproducible in Windows XP too.
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 184.108.40.206pre rendering.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Can someone set it to confirmed?
Any ideas Martijn ?
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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.
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
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.
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.
Minusing on the assumption that Boris is correct... usually a safe assumption :-)
Flags: blocking1.9? → blocking1.9-
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.
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.
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.