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...>, 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/106224Quoting 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.

On Monday 2012-04-02 11:24 +0800, Daniel Tan/BoltClock wrote:
> 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.Fundamentally, because if the spec didn't say this, then having
floats intersect with something that's scrollable would require the
browser to rewrap (around intruding floats) the contents of the
scrollable element every time it scrolls.  This is technically what
CSS 2.0 required, but it was never implemented, and it would have
been a huge problem for speed of scrolling.

-David

On 4/2/2012 11:35 AM, L. David Baron wrote:
> On Monday 2012-04-02 11:24 +0800, Daniel Tan/BoltClock wrote:
>> 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.
>
> Fundamentally, because if the spec didn't say this, then having
> floats intersect with something that's scrollable would require the
> browser to rewrap (around intruding floats) the contents of the
> scrollable element every time it scrolls.  This is technically what
> CSS 2.0 required, but it was never implemented, and it would have
> been a huge problem for speed of scrolling.
>
> -David
>This makes sense for 'auto' and 'scroll', but what about 'hidden'? The 
spec says that 'hidden' indicates that overflowing content is clipped, 
and that no scrolling UI should be provided for viewing content that 
gets clipped. Or is 'should' the keyword here, implying that a UA may in 
fact provide a means (scrolling or otherwise) to access content outside 
the clipping region?

On 4/2/12 12:02 AM, Daniel Tan/BoltClock wrote:
> This makes sense for 'auto' and 'scroll', but what about 'hidden'? The
> spec says that 'hidden' indicates that overflowing content is clipped,
> and that no scrolling UI should be provided for viewing content that
> gets clipped.While scrolling UI is not provided, the content is still scrollable 
programmatically, and a number of pages perform just such scrolling 
(e.g. by setting scrollTop on the relevant element).

-Boris

On 4/2/2012 11:35 AM, L. David Baron wrote:
> On Monday 2012-04-02 11:24 +0800, Daniel Tan/BoltClock wrote:
>> 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.
>
> Fundamentally, because if the spec didn't say this, then having
> floats intersect with something that's scrollable would require the
> browser to rewrap (around intruding floats) the contents of the
> scrollable element every time it scrolls.  This is technically what
> CSS 2.0 required, but it was never implemented, and it would have
> been a huge problem for speed of scrolling.
>
> -David
>Sorry to bring up this old thread. I'd completely forgotten about it. I 
do have something to clarify:

If the float is contained within an element whose overflow is other than 
visible, does it get clipped within that container element? If so, does 
the float affect any content that comes after the container element, or 
just the content that would have reflowed around it within the 
container? Or was none of this defined in CSS2.0?

It probably doesn't matter to implementers or authors anymore since it's 
been superseded, but I'm quite curious.