Here is what I think is happening.
Browser vendors seem to have decided that fixed
position elements that overflow have clipping turned off, e.g. they are not clipped by their parents. This makes things consistent, since fixed
elements are positioned relative to the window, not the parent. If clipping was applied, it would have position/width relative to the window and clipping relative to the parent. It would visually look like this (except the bottom corners should be rounded--more on that below).
So: fixed
element, no overflow clipping. Check.
But something changed in IE9. They introduced support for rounded corners. Now to what I said about the rounded clipping. IE9 actually did this right. Many browsers right now will clip with square corners, even when the element has rounded corners. This is bad. Apparently, IE9 fixed this by detecting the presence of rounded corners, and in such cases, re-drawing the clipping. When it does that, it makes two mistakes.
It applies the clipping--undoing the "fixed
element, no
overflow clipping" rule. Clipping is turned back on, and the element
is now clipped by the width of the parent.
The clipping is just put directly on the element,
un-centered, with no regards to the fact that the clipping is
supposed to be from the parent. It's just clipped starting at 0,0
out to the designated width and height--that's why the green element
appears left aligned--the right/bottom 50px are hidden.
Fixes?
- Don't nest
fixed
inside absolute
. (Best solution--avoid weird edge-cases in the future)
- Give the parent (red) div a width.
- Nest a new
div
directly inside .root
and move the overflow:hidden
to it. Fiddle example. (Least intrusive)
border-radius:30px
to.footer
and you can see that only the top-left corner is changed--this is because somehow the margin of the.root
is being inverted and is clipping.footer
(with rounded corner margin!). So that explains why changingoverflow
affects it, but I have no idea why the presence ofborder-radius
breaks it. – Tantalize