|
|
Posted by Ben C on 09/07/07 21:37
On 2007-09-07, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> Hello
>
> Consider the following HTML/CSS code
>
> http://home.comcast.net/~andrey-t/test_bump.html
[...]
> What I have there is two default-width fixed-height divs, one under
> another - yellow and green. The top div contains a square-shaped
> right-floated div (red), which is too tall for its parent, so it
> sticks out through the bottom (the parent div has 'overflow' set to
> 'visible').
>
> Now the question is: should the bottom div (green) bump into the
> protruding portion of the red div or should it span the full width of
> the parent as if the protruding portion is not there?
It should span the full width, like it does in Firefox.
Except when it starts a new block formatting context, which it does if
it's overflow: anything except visible (the default), as you've
discovered.
> In IE 7 the bottom div is reliably ignoring the red div. In Opera,
> Firefox and Safari the behavior of the bottom div depends on its
> 'overflow' property, which I find rather surprising.
It is rather surprising, but it's what the spec says.
> By default, the bottom div will "ignore" the red div, just like it is
> in IE.
Yes, although inline boxes in the green div will flow around the red
div, so it isn't completely ignored.
> But if I explicitly specify 'overflow: hidden' for the bottom div, it
> beings to "bump" into the red div, refusing to span the full with of
> the parent. I kind of thought that 'overflow' property is mostly
> intended to control "internal" behavior of the div (i.e. inner things
> that are trying to stick out), but in this case it appears to affect
> what I'd informally refer as its "external" behavior.
>
> Can anyone please shed some light on this issue? Why does 'overflow:
> hidden' make the bottom div to bump into the red div in this example
> in the abovementioned browsers?
Simple answer: because the CSS 2.1 spec says so. For a better answer
I can only offer the following speculation.
The point of a "block formatting context" is basically that it defines
the scope of floats. Normally floats visibly overflow their containers
and inline boxes (and other floats) in other nearby containers still
have to flow around them. But not across BFCs: an inline box will never
have to flow around a float from a different BFC.
That requirement is assisted by two further rules: (a) that BFCs grow if
necessary to contain their own floats completely, so they don't stick
out and get in the way of inline boxes in other BFCs; and (b) that BFCs
are themselves made narrower (or supposedly dropped down if necessary,
although no browsers I'm familiar with actually do that) to fit between
floats that may be to the sides of them. (b) is what you're seeing here.
These two rules (a) and (b) mean you shouldn't get floats obscuring
other elements in spite of restricting float/inline/float interaction to
same BFC.
Why though? Suppose that an element that was overflow: scroll, and that
its contents were allowed to be and were affected by floats from other
BFCs: it would have to be reflowed whenever it was scrolled. Suppose
floats inside it stuck out and got in the way of inline boxes in nearby
containers: _they_ would have to be reflowed whenever it was scrolled.
This would just be annoying for users.
Overflow: hidden doesn't present these problems, but it just seems to
have got lumped with overflow: scroll. There are similar reasons why
restricting the scope of floats in parent floats, table cells, and
positioned things makes life much simpler for the browser, which is
presumably why those things also all start new BFCs.
Note: the name is a bit confusing, because at first sight it looks like
"block formatting context" means "block box". But it does NOT mean that.
Lots of block boxes do not start new block formatting contexts, only
certain special ones (table cells, floats, positioned things, and things
with overflow other than visible).
Navigation:
[Reply to this message]
|