In CSS, we’re given a tool to explicitly control the stacking order of HTML elements: z-index. Elements with a higher value will appear on top:
Because .first.box has a larger z-index than .second.box, it stacks in front. If we remove that z-index declaration, it falls to the back. The code above is editable—give it a shot!
Things aren’t always so simple, however. Sometimes, the larger z-index value doesn’t win.
Check out what’s going on here:
.tooltip has a much larger z-index than header! So why on earth is the header on top?
To unravel this mystery, we’ll need to learn about stacking contexts, an obscure-yet-fundamental CSS mechanism. In this article, we’ll explore what they are, how they work, and how we can use them to our advantage.
the full list on MDN.
This can lead to some surprising situations. Check out what’s happening here:
main doesn’t set a z-index anymore, but it uses will-change, a property that can create a stacking context all on its own.
In order for z-index to work, we need to set position to something like relative or absolute, right?
Not quite. Check out what’s happening here:
The second box is lifted above its siblings using z-index. There are no position declarations anywhere in the snippet, though!
In order to understand what’s going on here, we need to learn about an iron-clad rule in CSS: only elements that create a stacking context can be given a z-index.
Remember the list we saw above? z-index will work in any of those situations. In this case, a stacking context is created by using z-index on a flex child (an element inside a container with display: flex).
In other words: it’s not that z-index only works with positioned elements. z-index works with any element that creates a stacking context. position: relative; z-index: 1 is one way to create a stacking context, but it’s not the only way.
Link to this heading
Hold on a minute…
There’s a Weird Thing here, and I think it’s worth pondering about for a minute or two.
In our Photoshop analogy, there is a clear distinction between groups and layers. All of the visual elements are layers, and groups can be conjured as structural helpers to contain them. They are distinct ideas.
On the web, however, the distinction is a bit less clear. Every element that uses z-index must also create a stacking context.
When we decide to give an element a z-index, our goal is typically to lift or lower that element above/below some other element in the parent stacking context. We aren’t intending to produce a stacking context on that element! But it’s important that we consider it.
When a stacking context is created, it “flattens” all of its descendants. Those children can still be rearranged internally, but we’ve essentially locked those children in.
Let’s take another look at the markup from earlier:
By default, HTML elements will be stacked according to their DOM order. Without any CSS interference, main will render on top of header.
We can lift header to the front by giving it a z-index, but not without flattening all of its children. This mechanism is what led to the bug we discussed earlier.
We shouldn’t think of z-index purely as a way to change an element’s order. We should also think of it as a way to form a group around that element’s children. z-index won’t work unless a group is formed.
Link to this heading
Airtight abstractions with “isolation”
