Re: [CSS21] 9.5.2 Effect of adjacent top margin of first in-flow child on clearance

Bruno Fassino wrote:
> On Sun, Jan 24, 2010 at 1:41 PM, Anton Prowse <prowse@moonhenge.net> wrote:
>>> The clearance computation include point 2 which says:
>>>
>>> "the distance to which _these margins_ collapsed when the hypothetical
>>> position was calculated"
>> It is not at all clear to me what "these margins" refers to.
>>
>>> (As a side note, that whole point 2 seems currently ignored by all
>>> browsers. Mozilla has the related bug 376365, don't know the others.
>>> Does this situation mean that the spec are possibly going to change
>>> here?)
>> As it stands, point 2 is completely incomprehensible to me, and I have
>> no idea how to test whether or not it has been implemented.  As I said
>> in that previous post, point 1 contemplates "the amount necessary to
>> place the border edge of the block even with the bottom outer edge of
>> the lowest float that is to be cleared", and I can't construct a
>> situation in which this is *not* the desired clearance.
> 
> 
> Point 2 should have an effect in a case like this
> 
> <div>Above</div>
> <div style="background:lime">
>   <div style="float:left; width:20px; height: 20px; background:blue"></div>
>   <div style="clear: left; margin-top: 30px; height:10px; background:red"></div>
> </div>
> 
> In absence of clear the 30px top margin goes outside the lime parent,
> pushing it down with the included float.
> Clearance is needed, it stops that collapsing so that the lime parent
> and the float move up.
> If the element with clear is positioned just below the float it ends
> up in a higher position than without the clear, with a negative
> clearance of -10px.
> I think point 2 should guarantee that this does not happen. Indeed it
> requires that clearance x satisfy:
> 0 (collapsing above clearance) + x + 30 (collapsing below clearance)
> >= 30 (collapsed value in 'hypothetical' computation)
> This implies that  x >= 0, so in this case the clearance should not
> become negative, it should stay at 0, and the top border edge of the
> element with clear should end up 10px below the float bottom edge (in
> the same position it was without the clear property).
>
> The above is essentially the same as this David Barons's test case
> http://dbaron.org/css/test/2007/0329-blog-examples/1

Oh, I see what you're saying!  It didn't cross my mind that the spec
might actually *want* the element C with clear to not not be flush with
the bottom of the float in certain situations, and hence take steps to
engineer this to happen!  (And that's despite that fact being the
obvious answer to my question, "When is the amount necessary «to place
the border edge of the block even with the bottom outer edge of the
lowest float that is to be cleared» *not* the desired clearance?".  This
confusion was entirely of my own making, since when I look back with
fresh eyes at the blog post[1] of March 2007 in which David introduces
the test case you mentioned, it is evident that he wanted the margin-top
of the clear to manifest itself somehow; I just really didn't imagine
that he, and the current spec, intended a /gap/ between the float and
the clear.)  If that is what's wanted, then point 2 suddenly becomes
clear to me.  What's more, thinking about your own example, I do think
it's desirable behaviour.

Thus I withdraw my objection/uncertainty about point 2 in both my
previous  and much earlier post (although I think the phrase "these
margins" could more explicitly refer back to the margins discussed two
paragraphs earlier, as I now interpret it to).

I also confirm that browsers do not seem to actually implement point 2 yet.

[1] http://dbaron.org/log/2007-03


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 24 January 2010 16:37:43 UTC