Position: relative; Stack Contexts, Stack Levels and HasLayout
#2 - what position:relative actually does, stacking changes
div class="a" - This div is just for kicks, removing it does change things slightly, well it did until headings went into place ~ so I think is a collapsing margin side effect, but that's another story
all divs have background color and borders to make the overlap clearer
.a {margin: 20px;}
div class="b" - This div has been given a zero bottom margin to make the overlap clearer
.b {margin: 20px 20px 0 20px;}
div class="c" - This div will be the one to watch ~ for layout or position: relative
it has the negative top margin and zero bottom margin to show it's relationship to previous and following elements
.c {margin: -20px 80px 0 80px; background: #ffc;}
.pr {position: relative;}
div class="d" - This is the following block with negative top margin again in order to show the stacking level reverts back
Spacing is controlled by <br> so padding and margins do not affect anything
.d {margin: -20px 50px 0 50px;}
What's happening here, position: relative; has been added to div "c" but NO z-index has been explicitly specified it is still auto.
Therefore it does not create a new stacking context.
Div "c" is now flipped in front of div "d" - In compliant browsers and IE7B2. This is perhaps not the authors desired effect but it is the correct one!. IE6 also flips div "c" to the "front", but doesn't correct the layout error in div "d", so it's likely that the fix of choice would have been be a hasLayout one in IE6 scenarios, which triggers a new problem for IE7
Fig.2: IE6 with position relative, psoition has changed but situation not improved
Now while seeming to look correct, as if a problem had been fixed, in IE7B2 it's quite easy to get it to produce a typical layout error by scrolling the page up and down (some div "c" borders disappear)
Fig.3: IE7 now display layout error, showing missing border after scroll
Flipping div "c" to the front is the right thing to do when position: relative is applied even though a new stacking context is not desired or given, div "c" now flips to the front because it is higher per the rules of stacking levels, all divs are still stacked according to the root context, but they are no longer at the same level within that context.
See Glossary: [01] stacking levels
Coming in at number 3 (nearer the back) we have - "a stacking level containing in-flow non-inline-level descendants", which all off these were until we changed the positioning of "c"
and now coming in at number 6 (nearer the front) we have - "a stacking level for positioned descendants with 'z-index: auto'," which div "c" now is, div d still belongs in level 3
So IE appear to have made some changes/stabilised the position: relative; property, but it's not perfect so we should not really consider it a fix for hasLayout rendering errors but there is a "new" connection between them.
lets change something to see a new connection >
| Previous : Page 1 | Glossary/References | Next : Page 3 |
Claire (Suzy) Campbell «tanfa.co.uk» © 2003-2008