Closed Bug 168160 Opened 22 years ago Closed 21 years ago

Mysterious gap before CSS floats with block level children


(Core :: Layout: Floats, defect, P3)






(Reporter: james, Unassigned)




(Keywords: css1, qawanted, testcase)


(1 file) shows an h1 followed by two
floating divs.  The text in the one on the left is contained in a block level p
element, whereas the one on the right uses an inline span.  Mozilla has
incorrectly drawn a white gap between the h1 and the left floated div, even
though padding, border and margin are all set to zero.  The problem does not
exist when all children of the div are inline, as in the right floated div.
Setting a border other than zero apparently eliminates the problem, as in, however in reality the gap
has just moved inside the float.  This second page is exactly the same apart
from both floats having a 1px dashed black top border.  The gap is still there,
only now it is coloured the green of the div rather than the white of the body.
Closed: 22 years ago
Resolution: --- → INVALID
The <p> has a default margin that's nonzero.  Given that, the rendering is
correct; setting the margin on the <p> to zero will also do what you want....
Why this bug resolution is INVALID? 
The p element is child of div#left.
So, the containing block of the p element is div#left's content box.

This problem is that the margin of p element has influenced out of parents.
The margin of the p element should not extend beyond the edges of it's
containing block.
Resolution: INVALID → ---
In this case it most definitely should extend outside the containing block. 
Read the section on margin-collapsing in CSS2 or CSS2.1
( and respectively). Note that
this also explains the behaviour you saw when you added a border, since margins
do not collapse through a nonzero border.

Closed: 22 years ago22 years ago
Resolution: --- → INVALID
From the CSS2.1 Spec:

>In this specification, the expression collapsing margins means that adjoining
> margins (no padding or border areas separate them) of two or more boxes (which
> may be next to one another or nested) combine to form a single margin.
> In CSS 2.1, horizontal margins never collapse.
> Vertical margins may collapse between certain boxes:
> * Vertical margins between a floated box and any other box do not collapse.
Resolution: INVALID → ---
Good point.

Confirming.  Ian and David, does this really mean to say what it says?  I
thought the intent was that floaters can collapse with things they contain but
not with siblings or their containers...

I have also sent mail to www-style regarding the issue.
Ever confirmed: true
Keywords: qawanted
OS: Windows XP → All
QA Contact: petersen → ian
Hardware: PC → All
We had a discussion of the bullet point below about positioned elements at the
Paris F2F (for those with W3C Member Access, see the very end of ), which is
partly wrong.  We didn't discuss floats.  What do other implementations do?

Note that CSS1 said something different from CSS2 -- it said that the margins of
floats do not collapse with *adjacent* elements.  See .

Thus this is a contradiction between CSS1 and CSS2, and at a minimum the working
group should add an errata item to the "Changes from CSS1" section (Appendix B)
of CSS2.

Fixing this would, I think, be close to a one line change -- setting the
NS_BLOCK_MARGIN_ROOT bit on floats (or their reflow states/contexts, or
something like that).
Keywords: css1
It would also seem helpful if the spec gave some way of selecting the background
when two collapsing margins would otherwise be different.
OS: All → Windows XP
Hardware: All → PC
OS: Windows XP → All
Hardware: PC → All
My knowledge of CSS margin may be wrong.(comment #2)
The child margin may have influence to parent margin.(when the parent has no
padding and no border)

Keywords: testcase
Priority: -- → P3
Target Milestone: --- → Future
It'd be good to get a clarification from the WG here...
Assignee: attinasi → float
Component: Layout → Layout: Floats
Priority: P3 → --
Target Milestone: Future → ---
A float's margins do not collapse with anything, not even in-flow children, as
of recent internal drafts of CSS2.1.
Priority: -- → P3
Target Milestone: --- → Future

*** This bug has been marked as a duplicate of 193461 ***
Closed: 22 years ago21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.