440042 - intrinsic width calculation doesn't account for float being next to contents of sibling block

Status: RESOLVED DUPLICATE of bug 396821

(Core :: Layout: Floats, defect)

Description

[Nikita Vasilev]

User-Agent:       Opera/9.50 (Macintosh; Intel Mac OS X; U; en)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ru; rv:1.9) Gecko/2008061004 Firefox/3.0

Firefox 3 doesn't render float correctly, but Firefox 2 does.

Reproducible: Always

Steps to Reproduce:
1. Open testcase



Reference rendering: http://elv1s.ru/files/html+css/float-float-block.png
Testcase: http://elv1s.ru/files/html+css/float-float-block.html

Comment 1

[Trenton D. ADams]

I can confirm this.  http://blog.trentonadams.ca does validate, and float:right on a div has no affect.  But, it works fine in other browsers.

Comment 2

[Trenton D. ADams]

FYI:
My post and commentlist classes use max-width of 600px.  If I remove the max-width, it works just fine.  So, hopefully that will help in identifying the piece of code that is causing the problem.

What firefox 2 does, is render the text beside my navigation as *less* than 600px (since there would be an overlap if it rendered it with 600px).  Then, once it passes below the navigation items, it gets to it's max-width of 600px.

Comment 3

[Trenton D. ADams]

Problem occurs on Mac OS X Leopard and Firefox 3.0 as well.

Comment 4

[Trenton D. ADams]

My "content" class, also had "float: left".  When I remove the "float: left", the problem disappears.  The content is supposed to be on the left, with the navigation on the right.  So, the question is, is this a bug?

I have made a snapshot of my theme in case anyone follows up on this, and needs to see my site in it's original form.

tar -cvzf honestexpressions-firefox-bugzilla-440042.tar.gz honestexpressions

Let me know...

Thanks

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

i can see this on windows too with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071903

Comment 6

[Teoh Han Hui]

I believe the behaviour in Firefox 3 is compliant with the CSS 2.1 visual formatting model.

See
http://www.w3.org/TR/CSS21/visuren.html#float-position
and
http://www.w3.org/TR/CSS21/visuren.html#comp-float

In you test case:
1. The outer float box is as wide as the inner element with the largest width.
2. The inner float box is removed from the normal flow of its containing block (does not occupy space) and contents in its containing block flow on its right.
3. Both the inner boxes are block boxes which occupy 100% width of the containing block. Thus, they cannot be placed next to each other.

Comment 7

[Teoh Han Hui]

Sorry for the oversight. You are right. The content of the other block box should not be flowed below as it is not an inline element of the containing block. Part of the other block box should be covered up by the inner float box (for its width of content + padding).

Comment 8

[Daniel.S]

Attachment: reporter's testcase

Comment 9

[Daniel.S]

This bug is either:

* valid, because the break between the float and the text inside the outer float shouldn't be taken into account when calculating the preferred width of the outer float.

* invalid, because the preferred width calculation of the outer float shouldn't take into account the width of the inner float at all.

David, I think you know the answer?

FYI, IE8 renders the same as earlier versions (without break).

Comment 10

[Ilya]

I believe that the bug is *valid*, because the CSS2.1 spec states that "non-positioned block boxes created before and after the float box flow vertically as if the float did not exist" (section 9.5, "Floats"), and section 10.3.5 ("Floating, non-replaced elements") suggests to calculate the preferred width of the float "by formatting the content without breaking lines other than where explicit line breaks occur". As far as I understand, this implies that there should not be the line break before the text of the 2nd block and that the preferred width of the outer float should include the width of the inner one. In my opinion, IE8+ and Presto-powered Operas render this case correctly.