See the Pen z-index-step2 by Pavel Pomerantsev. It has to be stacked on top of the main section, of course, so we’ll give it a z-index of 10:
Now, imagine we’re tasked with creating a dropdown menu in the header. In practice, components would live in separate files, and the markup would be generated using a JavaScript library of your choice, like React, but for demonstration purposes it’s fine to have everything together. We’re using a component architecture here, so CSS for the root component and every child component is defined in dedicated sections. See the Pen z-index-step1 by Pavel Pomerantsev. The main section for some reason has to have position: relative and z-index: 1. Let’s say we have a page with header and main sections. One of the most popular articles on z-index proposes grouping all z-index values in one place, but comparing those values doesn’t make sense if they don’t belong to the same stacking context (which might not be easy to achieve in a large application).
#Z STACKING HOW TO#
The main point of this piece, however, is how to deal with z-index when your page is composed of dozens and hundreds of components, each potentially having children with z-index defined. Note: It’s also great to be familiar with general paint order rules (which are actually quite complex). “ What No One Told You About Z-Index,” Philip Walton.“ The Stacking Context,” MDN web docs, Mozilla.There’s a bunch of online resources that do a great job in explaining these concepts in more detail: Notice the absence of div2-1 in the list - it’s a child of div2 which creates a stacking context (because it’s an absolutely positioned element with a z-index other than the default value of auto), so it’s painted after div2, but before div3.ĭiv1 doesn’t create a stacking context, because its implicit z-index value is auto, so div1-1 (its child) is painted after div2 and div3 (since its z-index, 10, is larger than that of div2 and div3).ĭon’t worry if you didn’t fully grasp this on first reading.
Going back to the example, the actual paint order of body’s descendant divs is: To put it another way, when an element creating a stacking context is painted, all its children are painted right after it and before any of its siblings. If an element is said to create a stacking context, it creates a basis for its children’s z-index values, so they’re never compared with anything outside the stacking context when determining paint order. Note that div2-1 is in fact overlapped by div3. So if we don’t take stacking contexts into account, the order should be as follows: If z-index values are the same, then the later it’s in the source, the later it’s painted. If an element has a higher z-index, it’s painted later. There are quite elaborate rules to determine paint order, but here we only need to compare two things: Let’s try to understand why we see what we see. See the Pen stacking-contexts by Pavel Pomerantsev. div1-1 is a child of div1, and div2-1 is a child of div2. They’re all absolutely positioned and overlap with each other. The document body has five div descendants: div1, div2, div3, div1-1, and div2-1. It would be best to explain the concept of stacking contexts by using an example. An element can create a stacking context which becomes the root for z-index values of its descendants. The z-index value space is not flat - it’s hierarchical.
There is, however, one major complication. So, the larger the z-index value, the later the element is painted on the page. You can also think of it as a property affecting paint order, and this will in fact be more correct since the screen is a two-dimensional grid of pixels. If you imagine the webpage as having three dimensions, then z-index is a property that defines the z coordinate of an element (also called its “stacking order”): the larger the value, the closer the element is to the observer. In this article, I’ll recap what z-index actually is and how you can stop guessing whether it might work in any specific case and start treating it just like any other convenient tool. Why does that happen? And more importantly, how to avoid such issues? If you’ve done any complex web UI development, you must have at least once furiously tried driving an element’s z-index up to thousands, only to see that it’s not helping position it on top of some other element, whose z-index is lower or even not defined at all. Adhering to some principles, however, we can easily avoid these issues. Stacking issues in a complex single-page web application can become a major pain. The z-index property, despite all that’s written about it, is still widely misunderstood and mishandled.
0 kommentar(er)
