Things are a little quiet around here so here's a quick little test for you debuggers
In the following example an element is floated but the following element doesn't float alongside as you may expect.
Who can explain this behaviour correctly?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>I am floated left</p>
<p>Why is this blue box underneath the float and not beside it?</p>
And for bonus points please explain why ie7 and under render the elements side by side? (this can be seen in action by using IE7 mode in the developer tools of ie10+).
I can't put it in technical terms, but I would expect the blue box to sit under and around the red box and the text inside it to wrap around the red box. Because of the width set on the blue box, although it still does sit under the red box, it is not wide enough to appear to wrap around the red box, but the text inside it still sits clear of the red box as best it can.
Ha! That's cute.
Both boxes are behaving correctly (the top of the blue box is under the red box) and the text is staying outside of the floated box.
I don't know the older IE bugs. I can see it in IE8 using IE7 mode, though.
What do you think will happen if we add overflow:hidden to .content? ... and why?
Adding overflow:hidden to .content should create a context for .content and keep it from flowing under .float (or so I think).
I believe what is happening is that the wrapping around a floated element occurs as if the wrapped around element was inline ( if that makes sense) . Since the floated object is wider than the object wrapping around it, the latter drops bellow it. This is best visualized by adding of margin-left : 300px OR width:500px to .content , then you can actually see the ‘wrapping’ behavior more clearly.
Overflow properties create a different rendering context. Similarly, you could use display:inline-block to achieve the same thing.
I am not sure about legacy IE (it’s been a while ) but I would hazard to guess that it has something to do with hasLayout.
Yes, .content's background will no longer slide under the float but it will now align to the side of the float instead (much in the way that may have been expected from the start).
The reason for this is one of [block formatting context which is what the overflow:hidden property imparts on .content. Once it has a block formatting content then the content must follow [URL="http://www.w3.org/TR/CSS2/visuren.html#bfc-next-to-float"]the rules from here](http://www.w3.org/TR/CSS2/visuren.html#block-formatting) which specifically state:
The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower.
This topic is now closed. New replies are no longer allowed.