I'm having a strangs CSS problem.
Below is a very simple code sample, demonstrating the problem.
<html>
<head>
<style>
.hover {
float: right;
}
.hover:hover {
background-color: blue;
}
.blocker {
opacity: 0.5;
}
</style>
</head>
<body>
<div class="hover">hover</div>
<div class="blocker">blocker</div>
</body>
</html>
I have a div A, floating over another div B, which has an opacity of 0.5. And I want to add a CSS hover rule to the floating div. But for some reason I can't.
Whether I float right or left, doesn't matter.
But when I change the opacity to 1, the hover rule works all of a sudden.
Can anybody explain this behaviour?
I can "fix" the problem by wrapping the content of the blocker div in a span, but it feels like I shouldn't have to.
Here's a jsFiddle, demonstrating the problem: http://jsfiddle.net/ed82z/1/
Simply put - it is "above" it if the opacity has a less than 1 value.
The key term here is a Stacking Context.
By setting opacity to a value less than one, it is layered differently according to the specification since it receives a new stacking context and is positioned beneath the element.
It is specified here float and in opacity:
The root element forms the root stacking context. Other stacking contexts are generated by any positioned element (including relatively positioned elements) having a computed value of 'z-index' other than 'auto'. Stacking contexts are not necessarily related to containing blocks. In future levels of CSS, other properties may introduce stacking contexts, for example 'opacity' [CSS3COLOR].
From opacity:
Since an element with opacity less than 1 is composited from a single offscreen image, content outside of it cannot be layered in z-order between pieces of content inside of it. For the same reason, implementations must create a new stacking context for any element with opacity less than 1. If an element with opacity less than 1 is not positioned, implementations must paint the layer it creates, within its parent stacking context, at the same stacking order that would be used if it were a positioned element with ‘z-index: 0’ and ‘opacity: 1’. If an element with opacity less than 1 is positioned, the ‘z-index’ property applies as described in [CSS21], except that ‘auto’ is treated as ‘0’ since a new stacking context is always created. See section 9.9 and Appendix E of [CSS21] for more information on stacking contexts. The rules in this paragraph do not apply to SVG elements, since SVG has its own rendering model ([SVG11], Chapter 3).
How to fix it:
You can set pointer-events to none , see this fiddle.
Adding overflow: hidden worked for me:
.blocker {
opacity: 0.5;
overflow:hidden;
}
Or:
.blocker {
opacity: 0.5;
position:relative;
z-index:-1;
}
(thank you #Eyal Barta for this option)
http://jsfiddle.net/ed82z/7/
This is because .blocker overlays your other div, easily shown with firebug or other dev tools.
When you add opacity you add a 'stacking context'.
This occurs because these DIVs have special properties which cause them to form a stacking context.
In this case: elements with an opacity value less than 1. Which is giving your div a z-index, and it is causing the div to be rendered in a different order.
The Stacking Context
In .blocker class is overlapping the .hover class because of float:right;
.blocker {
opacity: 0.5;
width:100px
}
you can fix this set float:left in blocker class or else set width:100px to fixed width for div it won't overlap.
Related
Today after hours of debugging, I learned in the hard way that:
A parent element is never able to cover (stack on top of) its child element if the parent has a z-index of any value, no matter how you change the child's CSS
How can I understand this behavior by logic? Is it in the specs?
.container {
width: 600px;
height: 600px;
background-color: salmon;
position: relative;
z-index: 99;
padding-top: 10px;
}
h1 {
background-color: pink;
position: relative;
z-index: -1;
font-family: monospace;
}
<div class="container">
<h1>1. I can never be covered by parent if my z-index is positive.</h1>
<h1>2. Even when my z-index is nagative, I still can never be covered if my parent has any z-index at all.</h1>
</div>
There are two important things you need to know: the painting order and the stacking context. If you refer to the specification, you can find how and when elements are painted.
Stacking contexts formed by positioned descendants with negative z-indices (excluding 0) in z-index order (most negative first) then tree order.
All positioned, opacity or transform descendants, in tree order that fall into the following categories:
All positioned descendants with 'z-index: auto' or 'z-index: 0', in tree order.
Stacking contexts formed by positioned descendants with z-indices greater than or equal to 1 in z-index order (smallest first) then tree order.
It's clear from this that we first paint elements with negative z-index at step (3), then the one with z-index equal to 0 at step (8), and finally the ones with positive z-index at step (9), which is logical. We can also read in another part of the specification:
Each box belongs to one stacking context. Each box in a given stacking context has an integer stack level, which is its position on the z-axis relative to other boxes in the same stacking context. Boxes with greater stack levels are always formatted in front of boxes with lower stack levels. Boxes may have negative stack levels. Boxes with the same stack level in a stacking context are stacked bottom-to-top according to document tree order.
To understand when each element will be painted you need to know its stacking context and its stack level inside this stacking context (defined by z-index). You also need to know whether that element establishes a stacking context. This is the tricky part, because setting z-index will do this:
For a positioned box, the z-index property specifies:
The stack level of the box in the current stacking context.
Whether the box establishes a stacking context
Values have the following meanings:
<integer>
This integer is the stack level of the generated box in the current stacking context. The box also establishes a new stacking context.
auto
The stack level of the generated box in the current stacking context is 0. The box does not establish a new stacking context unless it is the root element.
Now we have all the information to better understand each case. If the parent element has a z-index value of something other than auto, then it will create a stacking context, thus the child element will be painted inside whatever their z-index is (negative or positive). The z-index of the child element will simply tell us the order of painting inside the parent element (this covers your second point).
Now, if only the child element has a positive z-index and we set nothing on the parent element, then considering the painting order, the child will be painted later (in step (9)) and the parent in step (8). The only logical way to paint the parent above is to increase the z-index, but doing this will make us fall into the previous case where the parent will establish a stacking context and the child element will belong to it.
There is no way to have the parent above a child element when setting a positive z-index to the child. Also there is no way to have the parent above the child if we set a z-index to the parent element different from auto (either positive or negative).1
The only case where we can have a child below its parent is to set a negative z-index on the child element and keep the parent at z-index: auto, thus this one will not create a stacking context and following the painting order the child will be painted first.
In addition to z-index, there are other properties that create a stacking context. In case you face an expected stacking order, you need to consider those properties, too, in order to see if there is a stacking context created.
Some important facts that we can conclude from the above:
Stacking contexts can be contained in other stacking contexts, and together create a hierarchy of stacking contexts.
Each stacking context is completely independent of its siblings: only descendant elements are considered when stacking is processed.
Each stacking context is self-contained: after the element's contents are stacked, the whole element is considered in the stacking order of the parent stacking context. ref
1: there is some hacky ways if we consider the use of 3D transformation.
Example with an element going under its parent element even if this one has a z-index specified.
.box {
position:relative;
z-index:0;
height:80px;
background:blue;
transform-style: preserve-3d; /* This is important */
}
.box > div {
margin:0 50px;
height:100px;
background:red;
z-index:-1; /* this will do nothing */
transform:translateZ(-1px); /* this will do the magic */
}
<div class="box">
<div></div>
</div>
Another example where we can place an element between two elements in another stacking context:
.box {
position: relative;
transform-style: preserve-3d;
z-index: 0;
height: 80px;
background: blue;
}
.box>div {
margin: 0 50px;
height: 100px;
background: red;
z-index: 5;
transform: translateZ(2px);
}
.outside {
height: 50px;
background: green;
margin: -10px 40px;
transform: translateZ(1px);
}
body {
transform-style: preserve-3d;
}
<div class="box">
<div></div>
</div>
<div class="outside"></div>
We can also have some crazy stacking order like below:
.box {
width: 100px;
height: 100px;
position: absolute;
}
body {
transform-style: preserve-3d;
}
<div class="box" style="top:100px;left:50px;background:red;"></div>
<div class="box" style="top: 50px;left: 115px;background:blue;"></div>
<div class="box" style="top: 101px;left: 170px;background:green;"></div>
<div class="box" style="top: 175px;left: 115px;background:purple;transform: rotateY(-1deg);"></div>
We should note that using such hack may have some side effect due to the fact that transform-style, perspective and transform will affect position:absolute/fixed element. Related: Why does applying a CSS-Filter on the parent break the child positioning?
A good way to think about this is that each parent contains its own stacking context. Sibling elements share a parent's stacking order and may, therefore, overlap each other.
A child element is ALWAYS getting a stacking context based on its parent. Hence the need for a negative z-index value to push the child "behind" its parent (0) stacking context.
The only way to remove an element from its parent's context is using position: fixed since this essentially forces it to use the window for context.
The Mozilla documentation does say
The z-index CSS property sets the z-order of a positioned element and its descendants or flex items.
Here's some additional logic from another StackOverflow article relating to children vs descendants.
How can I understand this behavior by logic?
For me it's hard to understand your problem by logic. A parent contains its children. A bowl can be covered by another bowl. But you can't cover the soup with the bowl unless you put the soup out of the bowl.
z-Index sets the order for overlapping elements. A parent can't overlap its child.
ImhO that's perfectly logical.
This question already have a good answer, but I'd like to add one more thing: If you found this question, there's a good chance that your problem should be solved by overflow, not z-index.
So if I understand z-index correctly, it would be perfect in this situation:
I want to place the bottom image (the tag/card) below the div above it. So you can't see the sharp edges. How do I do this?
z-index:-1 // on the image tag/card
or
z-index:100 // on the div above
doesn't work either. Neither does a combination of anything like this. How come?
The z-index property only works on elements with a position value other than static (e.g. position: absolute;, position: relative;, or position: fixed).
There is also position: sticky; that is supported in Firefox, is prefixed in Safari, worked for a time in older versions of Chrome under a custom flag, and is under consideration by Microsoft to add to their Edge browser.
If you set position to other value than static but your element's z-index still doesn't seem to work, it may be that some parent element has z-index set.
The stacking contexts have hierarchy, and each stacking context is considered in the stacking order of the parent's stacking context.
So with following html
div { border: 2px solid #000; width: 100px; height: 30px; margin: 10px; position: relative; background-color: #FFF; }
#el3 { background-color: #F0F; width: 100px; height: 60px; top: -50px; }
<div id="el1" style="z-index: 5"></div>
<div id="el2" style="z-index: 3">
<div id="el3" style="z-index: 8"></div>
</div>
no matter how big the z-index of el3 will be set, it will always be under el1 because it's parent has lower stacking context. You can imagine stacking order as levels where stacking order of el3 is actually 3.8 which is lower than 5.
If you want to check stacking contexts of parent elements, you can use this:
var el = document.getElementById("#yourElement"); // or use $0 in chrome;
do {
var styles = window.getComputedStyle(el);
console.log(styles.zIndex, el);
} while(el.parentElement && (el = el.parentElement));
There is a great article about stacking contexts on MDN
Your elements need to have a position attribute. (e.g. absolute, relative, fixed) or z-index won't work.
In many cases an element must be positioned for z-index to work.
Indeed, applying position: relative to the elements in the question would likely solve the problem (but there's not enough code provided to know for sure).
Actually, position: fixed, position: absolute and position: sticky will also enable z-index, but those values also change the layout. With position: relative the layout isn't disturbed.
Essentially, as long as the element isn't position: static (the default setting) it is considered positioned and z-index will work.
Many answers to "Why isn't z-index working?" questions assert that z-index only works on positioned elements. As of CSS3, this is no longer true.
Elements that are flex items or grid items can use z-index even when position is static.
From the specs:
4.3. Flex Item Z-Ordering
Flex items paint exactly the same as inline blocks, except that order-modified document order is used in place of raw
document order, and z-index values other than auto create a stacking context even if position is static.
5.4. Z-axis Ordering: the z-index property
The painting order of grid items is exactly the same as inline blocks, except that order-modified document order is
used in place of raw document order, and z-index values other than auto create a stacking context even if
position is static.
Here's a demonstration of z-index working on non-positioned flex items: https://jsfiddle.net/m0wddwxs/
Make sure that this element you would like to control with z-index does not have a parent with z-index property, because element is in a lower stacking context due to its parent’s z-index level.
Here's an example:
<section class="content">
<div class="modal"></div>
</section>
<div class="side-tab"></div>
// CSS //
.content {
position: relative;
z-index: 1;
}
.modal {
position: fixed;
z-index: 100;
}
.side-tab {
position: fixed;
z-index: 5;
}
In the example above, the modal has a higher z-index than the content, although the content will appear on top of the modal because "content" is the parent with a z-index property.
Here's an article that explains 4 reasons why z-index might not work:
https://coder-coder.com/z-index-isnt-working/
Z-index needs these to work:
Position: relative, absolute, fixed, ..
Make sure that the parent element hasn't overflow: hidden;
I have had the same problem with z-index
and you believe me or not it's fixed just by setting the background color
like this
background-color: white;
If all else fails, look for syntax errors in your HTML. It's not intuitive, but I've seen it be the reason why z-index doesn't work.
The following code has invalid HTML syntax:
<div class="over"/>
<div class="under"/>
...(it's is invalid syntax because a div isn't a self closing tag).
CSS properties that were applied to these rogue HTML elements, such as background-color: black, position: fixed, width: 150px, and top:150px, were all working as expected. However, the z-index: 2 property wasn't working under the exact same conditions.
Only when the invalid HTML was fixed did the z-index work correctly.
I'm not sure why z-index was pickier than the other CSS attributes, but maybe this answer can help someone.
In my case I had my Navbar's opacity to 0.9, I got my answer from codercoder.com, as I removed the opacity property from my Navbar's css, z-index worked
just give position other that static. And u should give both container a position than it will work.
This question already has answers here:
Why can't an element with a z-index value cover its child?
(5 answers)
Closed 6 months ago.
Seems like I just found a bug or something. Usually when an element has a pseudo-element and I want it to show behind its parent I use z-index:-1. This works fine if the element has position relative or absolute but on position fixed something weird happens: the pseudo-element comes between the background and the text of the element like this:
div {width:200px;height:100px;position:fixed;background:black;display:block;}
div::after {content:"";position:absolute;top:0;width:100%;height:100%;background:red;z-index:-1;display:block;}
<div>
example
</div>
Can this be fixed so the pseudo-element goes completely behind the parent as it does with the other positions?
Thank you.
The behavior your are experiencing is due to stacking contexts in CSS:
A stacking context is formed, anywhere in the document, by any element in the following scenarios:
[…]
Element with a position value absolute or relative and z-index value other than auto.
Element with a position value fixed […]
So when you use position: fixed on the parent, it becomes a new stacking context, whereas when you use position: absolute or position: relative without a z-index, it is not a new stacking context, which is why you see this discrepancy in behavior.
When the parent element is a stacking context it becomes a "container" for position stacking. The text or other elements inside it are by default at the stacking position 0 but the pseudo element in your example has z-index of -1 so it goes behind the text. It does not go behind the parent because the parent itself is the container. It is like you have all these elements in a box and elements can't go outside the the box.
So to have the pseudo element be behind its stacking context parent, we can use a 3D transform to translate the pseudo element behind the plane of the parent. We add transform-style: preserve-3d so "that the children of the element should be positioned in the 3D-space" and then we can add transform: translateZ(-1px) to push the child element behind:
div {
width:200px;
height:100px;
position:fixed;
background:black;
display:block;
transform-style: preserve-3d;
}
div::after {
content:"";
position:absolute;
top:0;
width:100%;
height:100%;
background:red;
z-index: -1;
display:block;
transform: translateZ(-1px);
}
<div>
example
</div>
So if I understand z-index correctly, it would be perfect in this situation:
I want to place the bottom image (the tag/card) below the div above it. So you can't see the sharp edges. How do I do this?
z-index:-1 // on the image tag/card
or
z-index:100 // on the div above
doesn't work either. Neither does a combination of anything like this. How come?
The z-index property only works on elements with a position value other than static (e.g. position: absolute;, position: relative;, or position: fixed).
There is also position: sticky; that is supported in Firefox, is prefixed in Safari, worked for a time in older versions of Chrome under a custom flag, and is under consideration by Microsoft to add to their Edge browser.
If you set position to other value than static but your element's z-index still doesn't seem to work, it may be that some parent element has z-index set.
The stacking contexts have hierarchy, and each stacking context is considered in the stacking order of the parent's stacking context.
So with following html
div { border: 2px solid #000; width: 100px; height: 30px; margin: 10px; position: relative; background-color: #FFF; }
#el3 { background-color: #F0F; width: 100px; height: 60px; top: -50px; }
<div id="el1" style="z-index: 5"></div>
<div id="el2" style="z-index: 3">
<div id="el3" style="z-index: 8"></div>
</div>
no matter how big the z-index of el3 will be set, it will always be under el1 because it's parent has lower stacking context. You can imagine stacking order as levels where stacking order of el3 is actually 3.8 which is lower than 5.
If you want to check stacking contexts of parent elements, you can use this:
var el = document.getElementById("#yourElement"); // or use $0 in chrome;
do {
var styles = window.getComputedStyle(el);
console.log(styles.zIndex, el);
} while(el.parentElement && (el = el.parentElement));
There is a great article about stacking contexts on MDN
Your elements need to have a position attribute. (e.g. absolute, relative, fixed) or z-index won't work.
In many cases an element must be positioned for z-index to work.
Indeed, applying position: relative to the elements in the question would likely solve the problem (but there's not enough code provided to know for sure).
Actually, position: fixed, position: absolute and position: sticky will also enable z-index, but those values also change the layout. With position: relative the layout isn't disturbed.
Essentially, as long as the element isn't position: static (the default setting) it is considered positioned and z-index will work.
Many answers to "Why isn't z-index working?" questions assert that z-index only works on positioned elements. As of CSS3, this is no longer true.
Elements that are flex items or grid items can use z-index even when position is static.
From the specs:
4.3. Flex Item Z-Ordering
Flex items paint exactly the same as inline blocks, except that order-modified document order is used in place of raw
document order, and z-index values other than auto create a stacking context even if position is static.
5.4. Z-axis Ordering: the z-index property
The painting order of grid items is exactly the same as inline blocks, except that order-modified document order is
used in place of raw document order, and z-index values other than auto create a stacking context even if
position is static.
Here's a demonstration of z-index working on non-positioned flex items: https://jsfiddle.net/m0wddwxs/
Make sure that this element you would like to control with z-index does not have a parent with z-index property, because element is in a lower stacking context due to its parent’s z-index level.
Here's an example:
<section class="content">
<div class="modal"></div>
</section>
<div class="side-tab"></div>
// CSS //
.content {
position: relative;
z-index: 1;
}
.modal {
position: fixed;
z-index: 100;
}
.side-tab {
position: fixed;
z-index: 5;
}
In the example above, the modal has a higher z-index than the content, although the content will appear on top of the modal because "content" is the parent with a z-index property.
Here's an article that explains 4 reasons why z-index might not work:
https://coder-coder.com/z-index-isnt-working/
Z-index needs these to work:
Position: relative, absolute, fixed, ..
Make sure that the parent element hasn't overflow: hidden;
I have had the same problem with z-index
and you believe me or not it's fixed just by setting the background color
like this
background-color: white;
If all else fails, look for syntax errors in your HTML. It's not intuitive, but I've seen it be the reason why z-index doesn't work.
The following code has invalid HTML syntax:
<div class="over"/>
<div class="under"/>
...(it's is invalid syntax because a div isn't a self closing tag).
CSS properties that were applied to these rogue HTML elements, such as background-color: black, position: fixed, width: 150px, and top:150px, were all working as expected. However, the z-index: 2 property wasn't working under the exact same conditions.
Only when the invalid HTML was fixed did the z-index work correctly.
I'm not sure why z-index was pickier than the other CSS attributes, but maybe this answer can help someone.
In my case I had my Navbar's opacity to 0.9, I got my answer from codercoder.com, as I removed the opacity property from my Navbar's css, z-index worked
just give position other that static. And u should give both container a position than it will work.
Today after hours of debugging, I learned in the hard way that:
A parent element is never able to cover (stack on top of) its child element if the parent has a z-index of any value, no matter how you change the child's CSS
How can I understand this behavior by logic? Is it in the specs?
.container {
width: 600px;
height: 600px;
background-color: salmon;
position: relative;
z-index: 99;
padding-top: 10px;
}
h1 {
background-color: pink;
position: relative;
z-index: -1;
font-family: monospace;
}
<div class="container">
<h1>1. I can never be covered by parent if my z-index is positive.</h1>
<h1>2. Even when my z-index is nagative, I still can never be covered if my parent has any z-index at all.</h1>
</div>
There are two important things you need to know: the painting order and the stacking context. If you refer to the specification, you can find how and when elements are painted.
Stacking contexts formed by positioned descendants with negative z-indices (excluding 0) in z-index order (most negative first) then tree order.
All positioned, opacity or transform descendants, in tree order that fall into the following categories:
All positioned descendants with 'z-index: auto' or 'z-index: 0', in tree order.
Stacking contexts formed by positioned descendants with z-indices greater than or equal to 1 in z-index order (smallest first) then tree order.
It's clear from this that we first paint elements with negative z-index at step (3), then the one with z-index equal to 0 at step (8), and finally the ones with positive z-index at step (9), which is logical. We can also read in another part of the specification:
Each box belongs to one stacking context. Each box in a given stacking context has an integer stack level, which is its position on the z-axis relative to other boxes in the same stacking context. Boxes with greater stack levels are always formatted in front of boxes with lower stack levels. Boxes may have negative stack levels. Boxes with the same stack level in a stacking context are stacked bottom-to-top according to document tree order.
To understand when each element will be painted you need to know its stacking context and its stack level inside this stacking context (defined by z-index). You also need to know whether that element establishes a stacking context. This is the tricky part, because setting z-index will do this:
For a positioned box, the z-index property specifies:
The stack level of the box in the current stacking context.
Whether the box establishes a stacking context
Values have the following meanings:
<integer>
This integer is the stack level of the generated box in the current stacking context. The box also establishes a new stacking context.
auto
The stack level of the generated box in the current stacking context is 0. The box does not establish a new stacking context unless it is the root element.
Now we have all the information to better understand each case. If the parent element has a z-index value of something other than auto, then it will create a stacking context, thus the child element will be painted inside whatever their z-index is (negative or positive). The z-index of the child element will simply tell us the order of painting inside the parent element (this covers your second point).
Now, if only the child element has a positive z-index and we set nothing on the parent element, then considering the painting order, the child will be painted later (in step (9)) and the parent in step (8). The only logical way to paint the parent above is to increase the z-index, but doing this will make us fall into the previous case where the parent will establish a stacking context and the child element will belong to it.
There is no way to have the parent above a child element when setting a positive z-index to the child. Also there is no way to have the parent above the child if we set a z-index to the parent element different from auto (either positive or negative).1
The only case where we can have a child below its parent is to set a negative z-index on the child element and keep the parent at z-index: auto, thus this one will not create a stacking context and following the painting order the child will be painted first.
In addition to z-index, there are other properties that create a stacking context. In case you face an expected stacking order, you need to consider those properties, too, in order to see if there is a stacking context created.
Some important facts that we can conclude from the above:
Stacking contexts can be contained in other stacking contexts, and together create a hierarchy of stacking contexts.
Each stacking context is completely independent of its siblings: only descendant elements are considered when stacking is processed.
Each stacking context is self-contained: after the element's contents are stacked, the whole element is considered in the stacking order of the parent stacking context. ref
1: there is some hacky ways if we consider the use of 3D transformation.
Example with an element going under its parent element even if this one has a z-index specified.
.box {
position:relative;
z-index:0;
height:80px;
background:blue;
transform-style: preserve-3d; /* This is important */
}
.box > div {
margin:0 50px;
height:100px;
background:red;
z-index:-1; /* this will do nothing */
transform:translateZ(-1px); /* this will do the magic */
}
<div class="box">
<div></div>
</div>
Another example where we can place an element between two elements in another stacking context:
.box {
position: relative;
transform-style: preserve-3d;
z-index: 0;
height: 80px;
background: blue;
}
.box>div {
margin: 0 50px;
height: 100px;
background: red;
z-index: 5;
transform: translateZ(2px);
}
.outside {
height: 50px;
background: green;
margin: -10px 40px;
transform: translateZ(1px);
}
body {
transform-style: preserve-3d;
}
<div class="box">
<div></div>
</div>
<div class="outside"></div>
We can also have some crazy stacking order like below:
.box {
width: 100px;
height: 100px;
position: absolute;
}
body {
transform-style: preserve-3d;
}
<div class="box" style="top:100px;left:50px;background:red;"></div>
<div class="box" style="top: 50px;left: 115px;background:blue;"></div>
<div class="box" style="top: 101px;left: 170px;background:green;"></div>
<div class="box" style="top: 175px;left: 115px;background:purple;transform: rotateY(-1deg);"></div>
We should note that using such hack may have some side effect due to the fact that transform-style, perspective and transform will affect position:absolute/fixed element. Related: Why does applying a CSS-Filter on the parent break the child positioning?
A good way to think about this is that each parent contains its own stacking context. Sibling elements share a parent's stacking order and may, therefore, overlap each other.
A child element is ALWAYS getting a stacking context based on its parent. Hence the need for a negative z-index value to push the child "behind" its parent (0) stacking context.
The only way to remove an element from its parent's context is using position: fixed since this essentially forces it to use the window for context.
The Mozilla documentation does say
The z-index CSS property sets the z-order of a positioned element and its descendants or flex items.
Here's some additional logic from another StackOverflow article relating to children vs descendants.
How can I understand this behavior by logic?
For me it's hard to understand your problem by logic. A parent contains its children. A bowl can be covered by another bowl. But you can't cover the soup with the bowl unless you put the soup out of the bowl.
z-Index sets the order for overlapping elements. A parent can't overlap its child.
ImhO that's perfectly logical.
This question already have a good answer, but I'd like to add one more thing: If you found this question, there's a good chance that your problem should be solved by overflow, not z-index.