Managing Z-Index At A Component-Based Web Application

Handling Z-Index At A Component-Based Web Program

Pavel Pomerantsev

2019-04-03T14:00:08+02:00
2019-04-09T17:06:56+00:00

(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 none (see full rules) and its own z-index (0 by default) is lower than that of the primary section (1).
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 10:
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 div1, and div2-1 is a child of div2.
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 z-index defined.
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.
To recap:

One of the most popular posts on z-index proposes group all z-index values in one location , 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).

  • div1
  • div2
  • div3
  • div1-1
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 position and z-index worth other than the default ones (which can be static and auto, respectively).

Note: It’s also good to be familiar with overall paint order rules (that are really very complicated ).

Smashing Editorial
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:

Note that 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 div3.

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
  • Z-index Values
    If an element has a higher z-index, it’s painted afterwards.
  • Source Purchase
    In case z-index values are the same, then the after it is in the source, the later it is painted.

We’re using a component design here, so CSS for every child component and your root component is described in sections. For demonstration purposes it is nice to have everything together, along with the markup would be generated with a JavaScript library of your own choice although in practice, components would live in separate files.
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 translateZ 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?