Google Maps, Z Index and Drop Down Javascript menus

Question

I've run on a little problem today: I have a JS drop down menu and when I inserted a GoogleMap... the Menu is rendered behind the Google Map... Any ideas on how to chance the z Index of the Google Map?

Thanks!

Answer 1

If your problem happens in Internet Explorer, but it renders the way you'd expect in FireFox or Safari, this link was extraordinarily helpful for me with a similar problem.

It appears to boil down to the idea that marking an element as "position:relative;" in CSS causes IE6&7 to mess with it's z-index relative to other elements that come before it in the HTML document, in unintuitive and anti-spec ways. Supposedly IE8 behaves "correctly" but I haven't tested it myself.

Anutron's advice is going to be really helpful if your problem is with a <SELECT> form element, but if you're using JavaScript to manipulate divs or uls to act like a drop down I don't think it's going to help.

Answer 2

Note that dropdown menus in some browsers (ahemIE*ahem) cannot be zPositioned at all. You'll need to use an "iframe shim" to obscure it or hide the dropdown entirely if you want to position something above it. See: http://clientside.cnet.com/wiki/cnet-libraries/02-browser/02-iframeshim

Answer 3

The map is already wrapped inside a div. Give it a negative z-index and it works - with one caveat: the gmaps controls aren't clickable.

Answer 4

If your menu is wrapped in a div container e.g. #menuWrap then assign it position relative and give it a high z-index.... e.g.

#menuWrap {
  position: relative;
  z-index: 9999999
}

Make sure your map is inside a div

Answer 5

Try setting your menu z-index insanely high. Apparently Google Maps uses a range from -9000000 to 9000000.

Answer 6

Wrap the map in a DIV, give that DIV a z-index of 1. Wrap your drop-down in a DIV and give it a higher value.

Answer 7

IE gives the problem

every div that is wrapped in a relative positioned div will start a new z-index in IE. The way IE interprets the outer relative divs, is in order of html. Last defined is on top. No matter what the z-indexes of the divs inside the relative positioned divs are.

Solution for IE: define the div that should be on top at last in html.

(So z-index does work in IE, but only per holder div, every holder div is independent of other holder divs)

Answer 8

z-index (especially in Internet Explorer 7) really didn't work for me. I tried many different combination's of high vs. low map z-indices but had no joy.

By far the simplest/quickest answer for me was to re-arrange my mark-up/css to have my flyouts/rollovers listed in the mark-up above/before my map (literally, before the <div id="map">), this way I could let the z-index remain default (auto) and move on to more important aspects of my webapp ;)

Hope this helps!

<ul id="rollover">
<li><a href="#here">There</a></li>
</ul>
<div id="map">...</div>

Answer 9

I created a google style drop-down and had the same issue...using the V3 api for google maps, you just create a control and place it on the map using:

map.controls[google.map.ControlPosition.TOP].push(control);

Since it is a drop-down, just make sure the z-index of the containing div is highest (z=3) then the drop-down part containing the menu items is lower that the containing div (z=0).

Here's an example.

From my experience, the only time you need to use shims is for plug-ins (like with Google Earth).

Answer 10

No need to set the z-index for both the map and the menu. If you simply set the z-index of the menu higher than the map, it won't necessarily work.

Set the z-index of the map div to -1. Now the menu will drop down and display over the map.........but if you're using a wrapper then the map will no longer be interactive as it is now behind the wrapper.

To work around this, use onmouseover and onmouseout functions in your wrapper div. Make sure those are in your wrapper div and not your map div.

onmouseover="getElementById('map').style.zIndex = '10000';" 

onmouseout="getElementById('map').style.zIndex = '-1';"

Answer 11

I've found that sometimes inadvertently neglecting to declare the !doctype will cause this kind of hiccup in IE, when other browsers seem to be able to negotiate the page fine.