## DEV Community

Natalia Venditto for This is Learning

Posted on • Updated on

# CSS z-index illustrated

My followers know that I no longer work as a frontend developer, however, I worked as one for nearly 15 years and I was self-taught. I was lucky to have a background in architecture, CAD and graphic and 3d design, so grasping the more mathematical (or in this case geometrical) aspects of putting together a layout, was not difficult for me. However, I see that for self-taught developers coming from completely unrelated backgrounds, the `z-index` is a tough one to grasp.

This is my attempt at explaining it in an illustrated way.

Most people will be familiar with the concept of cartesian coordinates. They are used to define the location of a point in either a line (2d) or in space (3d). If you drive and use Google Maps, you are probably familiar with geospatial coordinates, or longitude and latitude; the points we use for locations on maps or Earth.

### 2d or two dimensional

In `2d`, we have the `y-axis`, and the `x-axis`. From their convergence, the point (0,0), we can then specify where another point is located. Typically the `y-axis` defines the vertical location, and the `x-axis` the horizontal location of a point.

If we have several points that define a shape, like a box, then we can define its dimensions AND its location, using coordinates.

This is basically how we do layout with css, defining the dimensions and location of elements with respect to those two imaginary lines that come defined by the edge of the viewport.

We understand `y=0` as the top of the browser viewport, and `x=0` as the left edge (when left to right), so (0,0) would be the most top-left point as we load the page (considering it is not programmatically scrolling to another `x,y` location).

### Layout and the box model

When we are adding new elements to the markup of a page, by default they're added to the default context (I will explain context later in the article). They will follow the document flow and be stacked on top of each other, in the same order they are added to the document.

So if we had 3 block elements like `divs` for example, added to a document like you see in the figure below, if we could see them from the side in terms of an imaginary vertical stack, they would be stacked in this way:

But what would happen if you added a child to `div` number 2, and give it a top margin to move it on top of `div` 3 in the y-axis? That "overlapping" bit would be hidden by `div` 3, and that's expected, since in terms of markup `div` 3 is coming after `div` 4 in the document flow.

### z-index: 99999999999 !important will help...NOT

Many developers new to frontend will try to fix this using the `z-index` property, with a very high positive value (or maybe negative, supposign they wanted to completely hide the `div 4`). But that on its own, won't work.

EDIT: Originally I had written -> "If you don't create a new stacking context, z-index won't work, no matter how many 9's and `!importants` you add." ** I will address Temani Afif comments below, stressing this: the new stacking context is created when position is set to ‘fixed’, ‘sticky’ or ‘relative’ and z-index is set to anything other than ‘auto’. Position on its own removes the element from the document flow, which means it no longer follows the order in the markup as elements are painted. However, it remains in the same stacking context.

## Understanding stacking contexts

Let's port that two-dimensional representation of cartesian coordinates, to a three-dimensional or spatial one. As you probably guessed, now we have 3 points that specify the location of a point: (x, y, z)

A stacking context is each new layer added to that z-axis, that you can now reorder, to bring elements on top or place them below the default context or other contexts.

The order comes defined by the index, that can be 0, a positive integer or a negative integer or auto.

I advise you now head to the official documentation on MDN, and read all you can about stacking contexts. But in a nutshell, you create a new stacking context by giving a container div the following properties and values:

• you give it an `opacity` different than 0
• you give it a `position` other than `static`, and a `z-index` other than `auto`
• you give it `display` either `flex` or `grid`, and a `z-index` other than `auto`
• you use `transform`, `perspective`, `filter`, `clip-path` or `mask`
• or you use some of the brand new properties, such as `isolate`(with a value of `isolate`), `will-change`, or `contain`.

That's all folks! I hope you find it useful and don't have to struggle with z-index issues anymore! Also if this article has an error or you want to suggest an improvement, do it in the comments!

Comment deleted

Comment deleted

Natalia Venditto

A stacking context will simply tell you where each element belong because we have another important concept which is the painting order and this one will decide which element will be above or below another one.

The importance of order is already mentioned in the article, although I don't refer to it by the technical term "painting order"

Comment deleted

Natalia Venditto

Yes, that's a nuance. But it definitely weighs in the decision.

Natalia Venditto

Actually position: XYZ other than static does create a stacking context as I supposed developer.mozilla.org/en-US/docs/W...

And point number 5 of the documentation.

All non-positioned floating descendants, in tree order. For each one of these, treat the element as if it created a new stacking context, but any positioned descendants and descendants which actually create a new stacking context should be considered part of the parent stacking context, not this new one.

w3.org/TR/CSS2/zindex.html

Comment deleted

Natalia Venditto

Yes, only if z-index is different than auto is true and it's already described in the article. When you give it a position and no z-index at all computed, it also works.

👍

Comment deleted

Natalia Venditto • Edited

I think we are simply saying exactly the same only that you are going a lot more in-depth than I intended in this article. I did not describe all the edge cases and potential implications because I invited readers to delve in the docs. But it’s cool, however I feel a disconnect when you mention terms such as DOM and tree hierarchy which I never used through my article. I spoke about document flow only. And also some corrections made on incorrect interpretation. So at this point I feel we could reconduct the debate and focus on the original point of the article which I think satisfies the intention. Great talking to you!

Comment deleted

Natalia Venditto

That's true. It can also be auto.

Natalia Venditto

I am not sure I say the viewport is a stacking context. I illustrate the stacking context with respect to the viewport.

Comment deleted

Natalia Venditto

No, I never say the viewport is a stacking context. I just illustrate it so there is a reference.