Aleksandar • Vacić

iOS bits and pieces

IE "phone-book"

This one’s very bad one.

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

example layout structure - gecko/khtml/opera display

  • 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.

example layout structure - IE display

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 2nd relative block element was showing above the content of the 1st 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.