Z索引无法正常工作

Question

Page in question:

http://meyers.ipalaces.org/sitemap/

The first <LI> should be z-index: 2; and should be on top of any other <LI> further down. (Meyers)

CSS:

.sitemap #primaryNav > ul > li {
    float: none;
    background: #ffffff url('images/L1-left.png') center bottom no-repeat;
    z-index: 2;
    position: relative;
}

The idea is that the background color of #fff should be ontop of the <LI> 's below, therefore creating an effect similar to this:

http://astuteo.com/slickmap/demo/

if you use firebug on the above link and disable position:relative from #primaryNav #home You'll see that it looks like mine. I am not sure how to get it to be like theirs.

Answer 1

First thing I would point out is that, in your case, "home" is not the origin in the sitemap. While might want it to seem that way visually, semantically this is not the case. SlickMap understands this (or maybe they just got lucky), which is why in their html the "home" li is at the same level as the other primary pages. The only thing above other pages is the root, which has no page (though most people redirect root to the "homepage").

Second, once a parent's z-index is set, unless the child is set to position: absolute and the parent is not set to position: relative , all children are considered to start one level above the parent in regards to stacking order. This is defined in the CSS 2.1 standard under 9.9.1 Specifying the stack level: the 'z-index' property as (emphasis mine):

The order in which the rendering tree is painted onto the canvas is described in terms of stacking contexts. Stacking contexts can contain further stacking contexts . A stacking context is atomic from the point of view of its parent stacking context; boxes in other stacking contexts may not come between any of its boxes.

So, while SlickMap was able to tell you:

The first <LI> should be z-index: 2; and should be on top of any other <LI> further down.

In your design doing so makes no difference because moving the first li upwards moves all of it's children with it. And, since the children in your home block start their own stacking context one level higher than the parent, your "home" li can never be above the items inside it.

Now that that is out of the way. I reviewed your code with the SlickMap code to understand the differences. As you can see below, there is pretty much only one reasonable option here that is going to be 100% compatible.

z-index does support negative numbers but, since the stacking context is different between "home" and it's siblings, you cannot use that here. However, if each child of "home" was set to position: absolute and the "home" li was set to position: static (the default) you could, in some edge cases, use z-index: -1 on those children and make them appear to be behind the parent. But, you have to have other variables available as well (such as the parent's parent's background being transparent) AND , most importantly, you would have to position each child manually. Clearly this is not a good idea. Not to mention negatives in z-index is buggy in IE6/7.

What you need to do is, as SlickMap did, merge the first ul under the li containing "home" with ul.level--0 . This will result in the following hierarchy:

ul
--Home
--Meyers
    --Another Level
--M....
    --Another Level
--etc

Then, you should be able to apply z-index: 2 to the "home" li and you will get the result you are looking for. Obviously, the change in structure will likely require other changes to your styles as well.

There are probably some ways that CSS 3 properties could help you, but I dont want to get into that as I'm unsure your requirements.

Hopefully this lesson in CSS layout strcutres was helpful enough for you to make an informed decision on how to move forward with your project. If you have any addition questions about what I've said, just let me know.

Answer 2

Positioning and z-index won't be of any use, if the <li> you're trying to bring to the top layer is actually bringing the entire site map with it.*

Look at the source of your page side by side with Astuteo's code. There are a couple of places that you REALLY changed the markup:

Astuteo:     <ul id="primaryNav"> /* using natural block tags */
Meyers: <div id="primaryNav"><ul class="level--0"> /* wrapping without need */

Astuteo:      <li id="home"><a href....>Home</a></li> /* CLOSED li (immediately) */
*Meyers:  <li><a href...>Home</a>...the entire sitemap...</li> /* you wrapped the entire site map inside your first <li> */

Your desired solution essentially mirrors the original code. A rewrite or copy/paste at this point would probably be less time consuming than tracking down the remaining errors in syntax modification and/or layout strategy.

EDIT : have you tried something as simple as...removing the background property for the first-child of home?

<ul class="level--1">
    <li style="background: none">...

It would be something like this in your CSS (to keep your CSS out of your HTML):

.level--1 li:first-child { background:none; }

Answer 3

Well, it took a while to work out but I think I have it now. I must say that my Spidey sense was on high due to the fact that the page does not validate .

This is not really a z-index problem since you're using a 3rd party (and most excellent!) framework to style the HTML - SlickMap CSS which should work as advertised.

The problem isn't with the invalid markup although that should be fixed regardless. Namely that there are missing </li> tags, there is an invalid <br> in the utilityNav and duplicate id attributes in the main primaryNav .

The problem is that you have introduced extra <ul> levels and the CSS rules just don't match the correct elements any more. Is this required for any reason? I can see that this has tried to be corrected by adding child selectors to your CSS, but the markup is radically different to what the framework expects and hence the z-index stacking isn't correct.

With a minimal <ul> this demo works as expected since the HTML is correct for the SlickMap CSS. So I'd try and remove the extra <ul> levels from your markup and mimic the markup on the SlickMap demo page or my fiddle.

Hope this helps :)

Answer 4

The parent will need to have position relative to get a proper z-index stacking context. Super obscure, but maybe this will work for you?

Try reading through this link to get a better understanding of the (super obscure, no fault of yours) method of determining the stacking priority of DOM elements:

https://developer.mozilla.org/En/Understanding_CSS_z-index/The_stacking_context