The Blog

This one’s very bad one.

If you load up this page you’ll see a layout which has this structure:

• relatively positioned list, id=”topnav”
• static div below it
• relatively positioned div, id=”content”, which has some example content

In Mozilla, it apears as you (or at least I) would expect – menu goes above the remaining text. In IE, it goes below the Help section text, for reasons I thought had something to do with float + position:relative combo.

Real reason was this: when you define block element to be position:relative (content in my test case) this will not only reset the coordinate system for its child elements, it will also create a whole new dimension for z-index. Thus, an absolutely positioned element in the body with z-index: 400 (or I assume any other number) will go *below* the absolutely positioned (or floated) block with z-index:1 in the content div.

Update: I’m wrong here: new z-index context (dimension) will be created only if z-index is non-auto. Declaring only position:relative will not create new context.

This goes on for as much relative divs you have. In my example, content of 2^nd relative block element was showing above the content of the 1^st relatively positioned.

I named it after Michael Landis’s explanation on css-discuss list, who suggested that each pos:rel marks the beggining of the new set of pages, all above the previous ones.

Solution?
Whatever you come up with. I chose not to use position: relative in the dynamic drop-down menu I was building (and encountered this).

And now, the funniest thing: IE’s behavior is by-the-book (thanks to Big John who pointed this out to me). Yes, this is how W3C specs say it must work. I must admitt that I can’t see when would one want this to behave in this manner. But I can also just be grumdgy.

Bah…every day you learn something new.