views:

8191

answers:

3

Hi, I've isolated a little test case of IE7's z-index bug, but don't know how to fix it. I have been playing with z-index all day long.

What is wrong with z-index in IE7?

A: 

In IE6 in general, certain UI-elements are implemented with native controls. These controls are rendered in a completely separate phase (window?) and always appear above any other controls, regardless of z-index. Select-boxes are another such problematic control.

The only way to work-around this issue is to construct content which IE renders as a seperate "window" - i.e. you can place a selectbox over a textbox, or, more usefully, an iframe.

In short, you'll need to put "on-hover" like things such as menu's in an iframe in order to let IE place these above built-in UI controls.

This should have been fixed in IE7 (see http://blogs.msdn.com/ie/archive/2006/01/17/514076.aspx) but perhaps you're running in some kind of compatibility mode?

Eamon Nerbonne
i know about IE6 z-index bug - and this is fixed - but there's another issue with relatively/absolutely position elements/inputs in IE7 (which is fixed in IE8) - i found couple of solutions (playing with z-indeces), but none of them worked for - that's why I'm asking there...Anyway thx for the answer.
rezna
+20  A: 

Z-index is not an absolute measurement. It is possible for an element with z-index: 1000 to be behind an element with z-index: 1 - as long as the respective elements belong to different stacking contexts.

When you specify z-index, you're specifying it relative to other elements in the same stacking context, and although the CSS spec's paragraph on Z-index says a new stacking context is only created for positioned content with a z-index other than auto (meaning your entire document should be a single stacking context), you did construct a positioned span: apparently IE interprets this as a new stacking context.

In short, try adding this CSS:

#envelope-1 {position:relative; z-index:1;}

or redesign the document such that your spans don't have position:relative any longer:

<html>
<head>
    <title>Z-Index IE7 Test</title>
    <style type="text/css">
        ul {
            background-color: #f00; 
            z-index: 1000;
            position: absolute;
            width: 150px;
        }
    </style>
</head>
<body>
    <div>
        <label>Input #1:</label> <input><br>
        <ul><li>item<li>item<li>item<li>item</ul>
    </div>

    <div>
        <label>Input #2:</label> <input>
    </div>
</body>
</html>

See http://www.brenelz.com/blog/2009/02/03/squish-the-internet-explorer-z-index-bug/ for a similar example of this bug. The reason giving a parent element (envelope-1 in your example) a higher z-index works is because then all children of envelope-1 (including the menu) will overlap all siblings of envelope-1 (specifically, envelope-2).

Finally, IE6 has an additional bug that causes selectboxes and iframes to float on top of everything else.

Eamon Nerbonne
seems like you've found the problem - will check it in few moments, and will let you know...
rezna
finally solved it :) - the relative position is really anoying so I somehow adopted your idea without the 'envelope' elements - it seems to solve the problem and also to work - just have to redesign a bit the code for suggest box - thx a lot
rezna
You're welcome ;-)
Eamon Nerbonne
+1 - it helped me
metal-gear-solid
+1 works, but in my case i had to go up in parents almost to the body itself. Thanks by the way ;)
Beck
A: 

This bug seems to be somewhat of a separate issue than the standard separate stacking context IE bug. I had a similar issue with multiple stacked inputs (essentially a table with an autocompleter in each row). The only solution I found was to give each cell a decreasing z-index value.

jeremy