I added a fixed header to my site recently, and as a result I needed to set my content to have a z-index of a negative value to ensure that it wasn’t going over the header when scrolled down. The problem is, the individual elements are in a box with position: relative and the links are position: absolute. Both of those paired with the z-index makes the links unclickable. I’ve tried messing with the z-indexes but nothing seems to work. Here is a quick fiddle to show my issue: http://jsfiddle.net/7xEWs/1/
I’m not sure if there is another way or not to ensure my fixed header is displayed over the content without using z-index?
Are you trying to do something similar to what SitePoint has on their main site (http://www.sitepoint.com/)? To figure out what they did, use the Firefox Add-on Firebug (https://getfirebug.com/) or other modern browsers’ (i.e. Chrome, Safari, Opera) built-in developer tools to analyze SitePoint’s HTML and CSS. From a quick glance at SP’s code, the fixed header area is set to position: fixed with a high z-index of 9999 and a width: 100% and a height is set.
UPDATE: I just updated your JSFiddle with what I believe is what you were trying to achieve - http://jsfiddle.net/7xEWs/19/
I haven’t tested it in multiple browsers so you should do your due diligence and test, test, test.
I found the problem, I apparently had to increase the z-index on another div in the header for whatever reason, but it seems to work correctly now, no errors present.
I often give a z-index of 9999 to elements that need to always be on top but in the end I often find exceptions where another element also needs to be on top (at certain times) that I hadn’t accounted for so I end up sticking another 9 on the end so I’m probably no better off than if I had used a lower number to start with. It’s one of those things that you can’t always account for an no matter what you try there will always be exceptions where you need to adjust the stacking levels.
However in a complicated stacking environment I would avoid using z-index:1, z-index:2, z-index:3,4 ,5… and so on because at some stage you may want to insert an element between two others and you wouldn’t be able to do that unless you then revise all the other x-indexes above it. Much better to start with z-index:1,z-index:10,z-index:20; z-index:30 etc. That will leave you plenty of options to insert any elements between.
In normal layouts though it shouldn’t really matter as there would normally be few stacking levels to worry about.
Negative z-indexes are behind the body tag, which has a natural z-index of 0. I’m surprised the items didn’t flat out disappear on you, but maybe your body is transparent. In any event, you cannot interact with an element that lies behind another one, even if it is completely transparent.
Sorry to nitpick but I think I should clarify a little A negative z-index will not make an element go behind the background of the root element. Some very old browsers did this but they were wrong. Although not explicitly defined the implicit z-index level of the body element would be zero thus confining all elements to remain inside and visible.
A negative z-index will never place an element behind a positioned parent’s background where that parent has a z-index other than auto (except in IE7 and under where all positioned elements are given a z-index of “0” in error when indeed they should be auto). If a positioned parent (excluding the body element) has a z-index of auto then you can place things behind it (except in ie7 and under as already mentioned). Applying a z-index of auto to the body element will have no effect even if you add position:relative to it, it will effectively remain at zero.
