z-index
div {
z-index: 1; /* integer */
}The z-index property in CSS controls the vertical stacking order of elements that overlap. As in, which one appears as if it is physically closer to you. z-index only effects elements that have a position value other than static (the default).
Elements can overlap for a variety of reasons, for instance relative positioning has nudged it over something else. Negative margin has pulled the element over another. Absolutely positioned elements overlap each other. All sorts of reasons.
Without any z-index value, elements stack in the order that they appear in the DOM (the lowest one down at the same hierarchy level appears on top). Elements with non-static positioning will always appear on top of elements with default static positioning.
Also note that nesting plays a big role. If an element B sits on top of element A, a child element of element A can never be higher than element B.
Note that older version of IE get this context stuff a bit screwed up. Here's a jQuery fix for that.
More Information
- Screencast: How z-index Works
- MDN Docs
- Comprehensive article: Understanding z-index
- Rational z-index Values
Browser Support
| Chrome | Safari | Firefox | Opera | IE | Android | iOS |
|---|---|---|---|---|---|---|
| Works | Works | Works | Works | 4+ | 4+ | Works |
“Also note that nesting plays a big role. If an element B sits on top of element A, a child element of element A can never be higher than element B.”
That’s not quite right. In your illustration, “not child” will only be on top if the green box starts a stacking context, for which it needs z-index of anything except auto (or opacity of anything except 1.0). Just being position: relative doesn’t start a stacking context.
The main point about stacking contexts is that z-index can be used to rearrange the stacking order of elements only inside their own stacking context. That entire stacking context has a stacking position within its stacking context that’s determined by its z-index property and those of its siblings in that parent stacking context. Elements from different stacking contexts are therefore never interleaved in the final stacking order (this is what the spec means when it says stacking contexts are “atomic”).
If you think in terms of the “painters algorithm”, where objects are painted onto a scene back-to-front, then a stacking context is like a painting within a painting. You first paint everything in the stacking context back-to-front in the proper order, then slap the whole result in whereever it belongs when you come to paint its parent context.
With no z-index, things do stack pretty much in DOM order but with positioned stuff above, but it’s also worth mentioning that floats are also brought in front of non-floats (but behind the positioned boxes).
This had me caught out for a while earlier, so I thought I’d post a note here – don’t forget that z-index still respects parent’s overflow. So if you still can’t see something despite a z-index in the millions, check it’s not being cropped by an overflow:hidden
I was fighting with this for an hour until I read this comment! Thanks!
Yeah I was also struggling with the same issue of parent’s overflow being hidden and your comment saved me! Thank you!
Thanks, I’ve been fighting with z-index again today. For the first time I think I might be winning!
Hi, I have come across a issue where negative Z-Index does not work on IOS ipad 4. Its real bummer as it used to send a fullscreen BG to the back of my template which is useful as I dont have to assign Z-Index to all the other elements. Does any one know a suitable solution, maybe iOS as some of its own special commands which is the trend these days.? Cheers.