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?
views:
8191answers:
3
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
2009-08-17 12:02:52
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
2009-08-17 12:09:58
+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
2009-08-17 12:28:52
seems like you've found the problem - will check it in few moments, and will let you know...
rezna
2009-08-17 14:34:53
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
2009-08-17 15:27:49
+1 works, but in my case i had to go up in parents almost to the body itself. Thanks by the way ;)
Beck
2010-09-14 16:01:49
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
2010-04-20 03:38:56