Menu dropdown disappears

Sep 25, 2007 at 3:12 AM
Edited Sep 25, 2007 at 3:13 AM
Has anyone noticed that the menu dropdowns stay behind content controls of master pages and if there is something in front of them the menu disappears when you try to move down the list of items. Does anyone know how to fix this? Thanks

Sep 26, 2007 at 1:22 AM
Try adding a z-index property in your Menu's css setting it's value to a number bigger than any controls that the menu is going to overlap.

In my case is something like:

.MainMenu .AspNet-Menu-Horizontal
z-index: 300;
Sep 26, 2007 at 12:09 PM
I had to add
along with the z-index.
Oct 4, 2007 at 12:10 PM
IE will (violating standards) render certain elements on top of others disregarding z-index. (There was a KB article, but can't find it right now, attributing this to 'windowed' vs 'windowless' components but that explanation doesn't fit 100% with my observations).

In fact, I'm convinced M$ re-built this bug into IE7 on purpose.

This is, until either Microsoft fixes IE (not likely) or users get wise and IE's market share dwindles (ditto) or hell freezes over is IMHO one of the prime issues CSSfriendly faces.

Take a plain div and a plain input and try to float the div above the input using CSS - no dice. Take a DetailsView and put an Ajax Calendar in a templated field. Works. Now CSSfriendly the thing. All is still well in Firefox (Opera,Safari,..) but in IE, be it 7 or 6, the Calendar is gone unless there's only one or two fields below it, in which case it peeks out from under the end of the DetailsView. No amount of z-index tweaking helps here. Somehow, IE extends the illegal priorization of the input elements to the whole div surrounding it.

The only "solution" I found is to re-wrap the offending elements in tables. No matter whether you inefficiently wrap a 1x1 table around each input or revert to pre-CSSfriendly markup, only tables seem to convince IE to render input elements properly at the configured z-index.

Brian, did I miss something important?