.a {margin: 20px;}

.b {margin: 20px 20px 0 20px;}

.c {margin: -20px 80px 0 80px; background: #ffc;}
.l {zoom: 1;} 

.d {margin: -20px 50px 0 50px;}

What's happening here, zoom: 1; has been added to div "c" (position: relative removed for this part) in order to set the hasLayout=true. This is not as far fetched as it may seem, considering that heading divs often have a width on them or they contain an image [02] - thread containing samples or that it's been deliberately set to fix IE6 (re: page #2). It is more likely images in divs which will make this scenario more obvious.

images have hasLayout set to true by default [Source Microsoft] ~ and it is not possible to change an elements hasLayout status to false once it has been set.

So what is happening now, in Standards compliant browsers we revert back to demo #1, and default layering of the divs, because they just ignore the zoom property but even it were a width they would just treat it as width and nothing more. No positioning changes would be applied.

However, IE has changed! there is now a correlation between this hasLayout Demo and the position relative; one (re: page #2)

consider for a moment that we had used a hasLayout fix to workaround the display error in demo #1 for IE6, setting hasLayout would have produced the desired effect

Fig.4: IE6 now stable, and would likely have done what you wanted.

"div c" remains behind "div d" and the layout seems to have stabilised, so this would have been the correct solution at the time, however now In IE7B2, the layout trigger makes div "c" flip to the front in seemingly the same way that position: relative; does (see page #2)

Fig.5: IE7 also stable, but layouted element is staying on top of the following element

Ouch! - So how do we stabilise the layout and have div "d" come back in front of "c" well the only solution is to trigger hasLayout to true or use position: relative; on div "d" also. We now have an "snowball" effect because it could go on like this, with the layout errors compounding until the construct stops!

position:relative; set on "d" on it's own is not stable as Demo#2 shows in fact in slightly worsens from demo2 in BOTH IE6 and IE7B2, so a hasLayout fix is possibly still the safer option. The screenshots below show the effects I encountered while trying this solution.

Fig.6: IE6 with the position: relative; "fix" added to d. - missing borders div d

Fig.7: IE7 with the position: relative; "fix" added to d. now shows missing border on c and d

Also the point of the explanation of findings in Demo#2 is that position: relative; may just be affecting the elements stacking levels in ways that you don't expect or want.

Obviously the negative margin being used in this demo is not something that will always be present, but it's use in being able to move text in front of an image has brought this to attention recently. But also I think that layout errors like this might occur even if borders are touching or margins are adjoining and then collapsing, but more on that later if I can narrow that one down.

But surely this in an unnecessary demo... ermm you just shouldn't have set HasLayout to true in the first place?

I wish, but as mentioned earlier hasLayout can be triggered by an image (say in div c) and you can't change that, it is inherent to IE's "data structure" [03]. So this effect is likely going to occur over and over, only by the time the Layout error shows itself the problem could be difficult to pinpoint and more so the stacking context which caused it anyway!

Previous : Page 2

Glossary/References

Next : Conclusions

---

Claire (Suzy) Campbell «tanfa.co.uk» © 2003-2008