[CSS21] Why do overflow values other than 'visible' establish a new block formatting context?

In the following Stack Overflow question, we observe that applying 
overflow: hidden to a container element causes it to stretch to contain 
a floated image (assuming a default automatic height):

http://stackoverflow.com/q/9942026/106224

This is, of course, expected behavior. As stated in 
<http://www.w3.org/TR/CSS21/visuren.html#block-formatting>, applying an 
overflow value other than 'visible' to a box creates a new block 
formatting context for the box and its contents. For a container without 
a specific height (i.e. it's automatic), this causes it to stretch 
vertically until it can fully contain all of its descendants, floated or 
otherwise.

This leads us to wonder: why is this so? I am under the impression that 
removing floats from normal flow will interfere with clipping and 
scrolling, but am not sure how exactly. I can't seem to find any 
previous threads in the mailing list that discuss the overflow property 
in particular.

To that end, we have opened another question, which can be found in the 
following link. Since this does not appear to be covered in the 
formatting model spec, we would be grateful if we could obtain an 
authoritative view on it, as it would only invite pure speculation 
otherwise:

http://stackoverflow.com/q/9943503/106224

Quoting from the above question:

 > The CSS2.1 spec mandates that overflow other than visible establish a
 > new "block formatting context". This strikes me as odd, that a
 > property whose obvious purpose is to hide overflow without affecting
 > layout, actually does affect layout in a most major way.
 >
 > It seems like overflow values other than visible combine two
 > completely unrelated features: whether a BFC is created and whether
 > the overflow is hidden. It’s not like "overflow:hidden" is completely
 > meaningless without a BFC: because floats historically can overflow
 > their parent element, hiding the overflow without changing the layout
 > seems sensible.

Thanks in advance for any insights.

-- 
Daniel Tan/BoltClock
NOVALISTIC • Stellar Software Development & Design
<http://NOVALISTIC.com>

Received on Monday, 2 April 2012 03:25:03 UTC