Closed
Bug 404660
Opened 17 years ago
Closed 17 years ago
18|19px height + float content = next paragraph misaligned
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: folletto.id, Unassigned)
References
()
Details
Attachments
(4 files)
Basic test case (comment 0) screenshot.
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/523.12 (KHTML, like Gecko) Version/3.0.4 Safari/523.12
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
There's an alignment issue with a div with its height set to 18/19px and with another floated div inside. The following paragraph will be wrongly aligned to the end of the float instead of the left border of the page.
Works this way on Safari 2, 3 - Firefox 1, 2 - Explorer 5.5, 6, 7.
Newly broken in Firefox 3b1.
Reproducible: Always
Steps to Reproduce:
<html>
<head>
<title>Fx3b1 CSS Bug</title>
<style>
#before {
height: 18px; /* also 19px breaks */
}
#before div {
float: left;
}
</style>
</head>
<body>
<div id="before">
<div>---------------------------------------------------------------</div>
</div>
This should begin at the window left margin.
</body>
</html>
Actual Results:
The text after the nested divs (one with height=19px and the other floated) isn't aligned correctly.
Expected Results:
The text should be aligned to the left edge of the page.
Discovered on the website linked above and isolated to speed up the fixing task. :)
|
||
Comment 1•17 years ago
|
||
Can you attach a test case and a screenshot of what you see ?
Based on your code in comment 0, and the site in the URL I don't see anything wrong in the latest nightly build (the text after the div(s) is aligned correctly).
|
Reporter | |
Comment 2•17 years ago
|
||
I'm using Firefox 3.0b1, so maybe it has been already fixed... however, the test case should be the code above. I've tried again with a new HTML file using it and it's wrong, I can confirm it.
I'm attaching a screenshot of what I see on the test case. :)
|
|
Reporter | |
Comment 3•17 years ago
|
||
And here is how I see the specified website...
|
|
Reporter | |
Comment 4•17 years ago
|
||
Sorry for the attachment spam, but just to avoid any doubt, here the test case on the latest Minefield build I've found...
|
|
||
Comment 6•17 years ago
|
||
Ah, I see now. On the original url, one has to click the 'Trova' link to see the issue. (and in the testcase, I had originally wrapped the text that follows the 2 divs in a <p>; due to the default margins on that <p>, I didn't see the issue.)
This is invalid, I think.
The line box for the floated element is taller than 18px in the testcase. The computed height for that element is 20px on my set up (and 19px if the default font is set to 'serif'); as a result it protrudes out of the parent div, and pushes the text to the right of the floated element.
Gecko 1.9 is more exact in computing values, esp for font-sizing. Safari (e.g) displays the testcase as comment 0 expected it, because the computed value for the floated element is 18px.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
|
|
Reporter | |
Comment 7•17 years ago
|
||
Yes, it's absolutely something related to the evaluation of the font size: I first discovered that removing 'Arial' from the font-family on the website above with Firebug "resolved" the issue.
Now I was trying some other values, and using "overflow: hidden" fixes it as expected.
Also, it's interesting to see that adding a font-size: 18px; to #before in the test case above renders correctly in Fx2, but it's misaligned in both Safari3 and Fx3. So it's absolutely a font size computation variation.
|
|
||
Comment 8•17 years ago
|
||
The issue is that the float is not contained within the parent element, and thus affects the flow of text of subsequent elements.
overflow: hidden is a way to contain floated blocks.
You should search about 'containing floats'.
The Css-D Wiki ha some good resources; your favourite search engine has more.
http://css-discuss.incutio.com/?page=ClearingSpace
|
|
Reporter | |
Comment 9•17 years ago
|
||
Thanks Philippe, but I can assure you that there's no need of an explanation. And I smile since I would have done the same thing if I were you. :P ;)
The difference is just that the new more precise Fx3 rendering breaks something in some situations, since, like me, the CSS was tested against a different behavior.
As I've stated before, also Safari 3.0 has the same behavior, but it's "triggered" on one pixel less than Fx3. It seems that Fx2 evals the height at 18px, Fx3 at 20px and Safari 3.0 at 19px.
Since my design implicitly relied on that height, it broke on Fx3. :)
I just want to raise one question that isn't clear to me: with both font-size: 18px and height: 18px, the problem should disappear, since both the box and the text have the same height.... or am I wrong, since it triggers that behavior also on Safari?
You need to log in
before you can comment on or make changes to this bug.
Description
•