Managing Z-Index At A Component-Based Web Application
(dm, ra, il)
The design is currently broken, as you can see. An element with
z-index: 1 sits on top of an element with
z-index: 10, at the absence of some other
z-index rules. The reason is that the header now creates a stacking context — it’s a component with a
change property whose value is anything other than
see full rules) and its own
0 by default) is lower than that of the primary section (
In my experience, but this is seldom a problem. You could make in order for it not to intersect with all the header the overlay at the section go down rather than up. Or, if you really needed it to go up, then you could ditch the overlay HTML at the end of the body and give it a massive
z-index (“big” being whatever’s larger than the ones of other sections in the upper level). Whatever the situation, if you’re not in a competition to build the design, you should be fine.
Now, imagine we are tasked with creating a dropdown menu. It Must be piled on top of the main part, of course, so we’ll give it a
z-index of all
See the Pen z-index-step5 from Pavel Pomerantsev.
See the Pen
z-index-step7 from Pavel Pomerantsev.
Theyoverlap with one another and ‘re all absolutely positioned.
Div1-1 is a kid of
div2-1 is a child of
There is one complication. The
z-index value space is not flat — it is hierarchical. A component can make a stacking context which becomes the origin for
z-index worth of its descendants. It would be far better describe the concept by using a good example of stacking contexts.
The main point of the item, however, is how to take care of
z-index when your webpage consists of dozens and hundreds of components, each potentially having children with
Watch the Pen stacking-contexts from Pavel Pomerantsev.
The solution is a convention that eliminates the need for guesswork, and it is the following: changing z-indices within a component should only change that component, and nothing else. To put it differently, when dealing with
z-index values at a certain CSS document, we should ideally just concern yourself with different values in the exact same file.
One of the most popular posts on
group all , but assessing those values does not make sense if they don’t belong into the exact same stacking context (which may not be easy to accomplish in a huge application).
z-index values in one location
Watch on Codepen
This strategy will hopefully bring back some sanity .
Reaching it’s easy. We should simply make sure that the origin of every component creates a stacking context. The easiest way to do it is to provide it
z-index worth other than the default ones (which can be
Note: It’s also good to be familiar with overall paint order rules (that are really very complicated ).
Here’s a good example. Let’s say we’ve got a page with main and header sections.
If an element is believed to make a
stacking context, it creates a foundation for its kids’
z-index values, which means they are never compared with anything out the stacking context when determining paint order. To put it another way, once an element producing a context is painted, all of its children are painted right after it before any of its siblings.
If you didn’t fully grasp this on first reading, don’t worry. There’s a Lot of online resources which do a great job in explaining these concepts
This kind of architecture is not without its own drawbacks. It makes the program more predictable at the cost of some flexibility. For example, you will not Have the Ability to create these overlays inside both the header and the main part:
div2-1 is actually overlapped by
div3. Why is this happening?
(Note also that both have
position: relative because
z-index does not use to independently positioned elements
If you have done any complex web UI development, you must have at least once tried attempted driving a component’s
z-index up to tens of thousands, only to find that it’s not helping position it on top of some other component, whose
z-index is lower or not defined in any way.
Why we view what we see, let’s attempt to understand. There are quite elaborate rules to ascertain paint purchase , but we just need to compare two things:
If you imagine the webpage as having three dimensions, then
z-index is a property that defines the
z coordinate of a component (also called its”stacking sequence”): the larger the value, the nearer the element is to the audience. You may consider it as a home affecting paint arrangement, which will in fact be correct since the display is a grid of pixels. So, the bigger the
z-index value, the later the element is painted onto the page.
Why does that occur? And more importantly, how to avoid issues?
In the following article, I will recap what
z-index actually is and how you can stop imagining whether it might work in any specific case and begin treating it just as any other useful instrument.
See the lack of
div2-1 from the list — it’s a child of
div2 that creates a stacking context (because it is an absolutely positioned element with a
z-index other than the default value of
automobile ), therefore it is painted after
div2, but before
The Hierarchy Of Stacking Contexts See on Codepen
See the Pen
z-index-step3 from Pavel Pomerantsev.
See the Pen
z-index-step2 from Pavel Pomerantsev.
Watch on Codepen
Here is one of the techniques to structure the application. It uses more elements than the previous one, but computation associated with extra DOM elements is economical whereas developer’s time (many which can sometimes be spent on debugging stacking issues) is certainly not.
See on Codepen
If an element has a higher
z-index, it’s painted afterwards.
z-index values are the same, then the after it is in the source, the later it is painted.
Going back to this example, the actual paint order of
body‘s descendant divs is:
Now, a couple of months later, in order to make something unrelated perform better, we employ the hack into the header.
See the Pen z-index-step6 from Pavel Pomerantsev.
The issue is, how are we supposed to come for the alternative if we have components within components within components, each having components? How can we be confident that altering
z-index of this header won’t break anything else?
The solution is simple: provide the header a
z-index value of
2, and it’ll be fixed.
See on Codepen Watch on Codepen
If we examine the header code now, we will observe that we can remove the
z-index land from both the container and the overlay entirely because
the overlay is the sole positioned element there. Similarly, the
z-index isn’t required on the main container. This is the benefit of this suggested approach: it is just the element itself that matters, not its own context, when looking at z-indices.
So if we don’t take stacking contexts the order needs to be as follows:
Isolate components concerning
z-index worth of elements by making the origin of every element a stacking context;
You do not have to do it if no element within a component needs a
z-index value other than
Within a part’s CSS document,
values any manner you like. It may be sequential values, or you could give them a step of 10, or you may use variables — it all depends on your job’s conventions and also the dimensions of the part (although making components smaller is never a bad thing). Preferably, only assign
z-index to sibling elements. Otherwise, you may accidentally introduce more stacking contexts inside a component, and you’re confronted with the same issue again, fortunately on a smaller scale;
Debugging gets simple . Locate the very first ancestor part of the two components that aren’t piled correctly, and change z-indices within that component.