On Mar 23, 2010, at 12:27 AM, Bruno Fassino wrote:
>>>> The behavior of 'block formatting context roots' in presence of float
>>>> is not exactly defined in the spec, however all modern browsers
>>>> usually display them beside the float, making them narrower.
>>>>
>>>> I've recently noticed a strange behavior, both in Firefox 3+ and IE8,
>>>> occurring with boxes having overflow different from visible. Assume
>>>> there is a right float and then an overflow box with a negative left
>>>> margin. The box is rendered beside the float, but its margin is
>>>> ignored in Firefox 3+ and IE8. More details and test cases here [1].
>>>> I don't see any reason for such behavior, which looks simply wrong.
>>>> The strange thing is that it did not occur in Firefox 2 and IE7, so I
>>>> wonder if it could be intended. Has someone any ideas?
>>>>
>>>> [1] http://brunildo.org/test/bfc-neg-marg-float.html
>>>
>>> I not sure why this happens. I see that moving the position of the
>>> overflow box by a top margin (positive or negative) causes the
>>> overflow box to not ignore the left margin with -100px and for the
>>> overflow box not to be shorten by the float [1]. The last test with
>>> the overflow box with margin-top:-0.01em doesn't seem to be any lower
>>> visually.
>>>
>>> 1. <http://css-class.com/test/temp/overflow-floats-neg-margins.htm>
>>
>> Another weird one. The top margin seems to "disabled" the block formatting
>> context (it does not make the box shorter for the float). Imho, that one
>> goes against the spec.
>
>
> Yes, in the case with small negative top margin, Firefox seems to no
> more "see" the float. And this seems against the spec.
> (the case with top margin greater that the float, it's OK because the
> box is already below the float).
That is not limited to only Gecko (tested 1.9.2/Fx3.6 and the latest nightly
1.9.3a pre). I see the same behaviour with recent WebKit nightly builds, Safari
4.05 and Opera 10.5.
I tested this with
.box { margin-top:-.1em; }
Two other observations:
1. When I make the window small enough, Gecko moves the blue BFC box that has a
width applied to the left/right (test case 6a/6b). The window must be small
enough that the width of the box is larger than the available space.
2. Nightly WebKit builds: the blue BFC box with auto width and negative margin
is dropped below the floated box. This is different from what Safari 4.05 does
(this is also visible with the latest Chrome build on OS X - 5.0.356.2).
Bruno:
> I see indeed that Firefox ignores a negative margin on the same side
> of the float as well.
> ...
> Moreover, the spec now says:
> "the _border box_ of a table, block-level replaced element, or element
> in the normal flow that establishes a new block formatting context
> must not overlap any floats in the same block formatting context".
>
> They mention the "border box" and not the "margin box", so at least on
> the same side of the float, ignoring a negative margin is probably not
> so wrong?
That part is the correct behaviour, I think. If you give the box a (small)
positive margin on the same side of the float, it will be ignored. If that
margin is larger than the width of the float, it will be visible (Firefox 2.0 ,
IE 7 were all wrong; to be fair to Fx 2.0, the spec changed after it was
released).
With a negative margin, WebKit and Safari 4.05 do some strange things.
I don't have any good explanation for all that negative margin behaviour. Yet…
Philippe
---
Philippe Wittenbergh
http://l-c-n.com/
______________________________________________________________________
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
