W3C home > Mailing lists > Public > public-css-testsuite@w3.org > November 2013

Re: Issue with margin-collapse-clear-012.htm and margin-collapse-clear-013.htm

From: Alan Gresley <alan@css-class.com>
Date: Thu, 07 Nov 2013 10:36:55 +1100
Message-ID: <527AD297.5000706@css-class.com>
To: Robert Hogan <robhogan@gmail.com>, Bruno Fassino <fassino@gmail.com>
CC: Public CSS test suite mailing list <public-css-testsuite@w3.org>, Gérard Talbot <css21testsuite@gtalbot.org>
On 7/11/2013 6:23 AM, Robert Hogan wrote:
> Hi Bruno,
> So am I correct in understanding you to say that (1) regardless of the
> margin-top/margin-bottom values on self-collapsing-with-clearance it's top
> border edge should always be just after the float, (2) that when the
> margins of self-collapsing-with-clearance collapse together they do so at
> the position that is the computed value of the clearance from the top of
> the float (in this case 140px), with the result that any subsequent
> siblings use that clearance as their de-facto margin-top?
> After playing with this a bit more I think the result in IE and FF is
> because they are not collapsing margin-top and margin-bottom together. If
> you play with the margins in web inspector you'll see what I mean. Changing
> the negative margin-top value has no effect, while increasing the
> margin-bottom pushes the subsequent sibling down further.
> So maybe the answer is just to not treat the two margins as collapsing when
> we have clearance?
> Thanks,
> Robert

Hello Robert and Bruno,

I would say that they are not collapsing but more overlapping of the 
margin-top and margin-bottom since the border boxes are not aligned 

With the below code,

   <div id="parent" style="background: lime; border: 10px solid blue;">
     <div id="box" style="margin-top: 40px; margin-bottom: 80px; 
background: red;">
       <div style="float: left; background: orange;">float</div>

the border-top of the box is positioned 40px downward from the top edge 
of it's containing block (due to the margin-top) where the border-bottom 
is vertically aligned with the top edge of it's containing block. It's 
like the border-box has a negative height of -40px.

Right at the beginning of 8.3.1 is what margin collapsing is defined as.

   | Adjoining margins of two or more boxes (which might
   | or might not be siblings) can combine to form a single
   | margin. Margins that combine this way are said to
   | collapse, and the resulting combined margin is called
   | a collapsed margin.

Just the simple code above shows that the margin-top has not combined 
with the margin-bottom to form a single margin. Depending of which 
ancestor has which border-top or border-bottom, the border-top of the so 
called zero height border is vertically aligned with the top edge of 
it's containing block so child elements that are removed from the flow 
(e.g. floated or absolutely positioned) are positioned in respect to 
this top edge of this containing block. This test shows this.

<div id="wrapper" style="background: yellow; border-bottom: 10px solid 
   <div id="parent" style="background: lime; border-top: 10px solid blue;">
     <div id="box" style="margin-top: 40px; margin-bottom: 80px; 
background: red; position: relative;">
       <div style="position: absolute; background: red; height: 20px; 
bottom: 0;">a.p. bottom: 0;</div>
       <div style="position: absolute; background: orange; height: 
20px;">a.p. top: auto;</div>
       <div style="position: absolute; background: fuchsia; height: 
20px; top: 0;">a.p. top: 0;</div>

None of this appears in the spec but UAs behaves this way. Some 
constructions shows interoperability and others constructions causes 
usual rendering in some UAs.

Let's just get rid of the floats and understand zero height border boxes.


Now in the case of where there is a float, this construction with a 
negative height border box is simply moved downwards so the border box 
of the box with clearance is vertically aligned with the bottom of the 
float. The top-margin is simply underneath the float.



Alan Gresley
Received on Wednesday, 6 November 2013 23:37:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:20 UTC