Thanks Ingo, placing position: relative only on the "on" state fixed that z-index issue for me.
Ingo Chao wrote: > Dave Sherohman wrote: > >> I'm currently in the midst of reinventing the CSS cascading popup menu >> (with just a hint of javascript to do the show/hide, thanks to IE6's >> lack of li:hover) and have got it pretty well worked out in Firefox and >> Safari, but IE6 is killing me with its insistence on hiding bits of the >> popup behind the subsequent menu items. I've found lots of discussion >> about this bug via google, but no solutions (or at least none that I've >> been able to get to work). >> >> The test page I've been using to work this out is at >> http://kuno.sherohman.org/~esper/linktree/menutest.html >> > > > IE does erroneously establish a stacking context for elements with > position:relative without z-index. > > So in menu systems with position:relative on <li>, you get lots of > stacking contexts, one for each <li>. > > The submenu-<ul> inside the <li> cannot escape from it, whatever z-index > you'd choose. > > All subsequent <li> will be placed above the submenu, since these <li> > are coming later in the source. > > The generic approach to fix that problem is to set position:relative on > li:hover only. By doing this, the subsequent <li> will not be placed > above the hovered <li> in question, because only this li is positioined > and gets a higher rank in the painting order. > > Did you try that? > > Ingo > > ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
