On Tue, Mar 23, 2010 at 1:20 AM, Philippe Wittenbergh <[email protected]> wrote: > > On Mar 23, 2010, at 12:27 AM, Bruno Fassino wrote: >> 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).
Yes, with positive margins there is more consistency amongst modern browsers. The only anomaly that I see, with positive margin on the same side of the float, is that Safari 4 makes the b.f.c. box narrower than necessary, so there is a gap on the other side of the float, see http://brunildo.org/test/FloatMarginOverflow.html . Of course this is "allowed" by the spec. Thierry wrote: > The problem for us is that this behavior is different across browsers (but > what else is new?). and Ingo: > The other day, Tab Atkins Jr. explained what that means >> Often, "does not define" in CSS 2.1 means "browsers did all sorts of crazy >> things, and we decided not to try and stabilize the behavior at this time". Well, at least I see now a bit more consistency than few years ago :-) Bruno -- Bruno Fassino http://www.brunildo.org/test ______________________________________________________________________ css-discuss [[email protected]] 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/
