Div bumping and 'overflow' property

  • Thread starter Andrey Tarasevich
  • Start date
A

Andrey Tarasevich

Hello

Consider the following HTML/CSS code

http://home.comcast.net/~andrey-t/test_bump.html

(full code is quoted below)

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?

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. By default, the bottom div will "ignore" the red div,
just like it is in IE. 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?

The code below (and at the link provided earlier) contains two identical groups
of divs (three divs each) with the only difference of the bottom (green) div in
the second group having its 'overflow' property set to 'hidden'.

Thank you,
Andrey

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
<style type="text/css">
html { margin: 0; padding: 0; height: 100% }
body { margin: 0; padding: 0; height: 100%; background: silver }
div.content {
width: 70%; height: 100%; margin: 0 auto; background: white
}
div.top {
height: 50px; margin: 0; overflow: visible; background: yellow
}
div.bottom {
height: 50px; background: green
}
div.drop {
height: 90px; width: 90px; float: right; position: relative;
margin: 10px 10px 0 0; background: red
}
</style>
<head>

<body>
<div class="content">

<div class="top">
<div class="drop"></div>
</div>
<div class="bottom"></div>

<hr>

<div class="top">
<div class="drop"></div>
</div>
<div class="bottom" style="overflow:hidden"></div>

</div>
</body>
</html>
 
B

Ben C

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).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,023
Latest member
websitedesig25

Latest Threads

Top