为什么Clip-path（和其他属性）会影响DOM后面元素的堆叠顺序（z-index）？ [英] Why does clip-path (and other properties) affect the stacking order (z-index) of elements later in DOM?
问题描述
之前已经有人问过这个问题，但是只有在CSS中明确定义了 z-index 的情况下。
我试图在标题上使用clip-path，但随后从该元素下方的元素内的顶部标题上方拉出图像。但是，一旦我在标头上定义了 clip-path ，图像（它在堆栈顺序中应该更高，因为稍后在代码中出现）会变为在标题下面：
body {padding：1em;}标头{背景：＃a00;剪切路径：多边形（0 0，100％0，100％calc（100％-5em），0 100％）;} h1 {margin：0;填充：2em;字型：300％；白颜色; text-align：center;} section {background：#ccc; padding-top：5em; margin-top：-5em;} img {margin-top：-10em; }
< header> < h1>标题内容< / h1> / header<部分> < img src = https://via.placeholder.com/330/0000FF/808080 />< / section>
我希望图像位于标题的上方。在玩了一些之后，我发现如果我在图像上设置 position：relative -它可以工作：
body {padding：1em; }标头{背景：＃a00;剪切路径：多边形（0 0，100％0，100％calc（100％-5em），0 100％）; } h1 {margin：0;填充：2em;字型：300％；白颜色;文本对齐：居中； }部分{背景：#ccc; padding-top：5em;上边距：-5em; } img {margin-top：-10em;位置：相对； }
< header> < h1>标题内容< / h1> / header<部分> < img src = https://via.placeholder.com/330/0000FF/808080 />< / section>
但是为什么呢？请在这里发生什么，为什么剪贴路径似乎会影响页面后面元素的堆叠顺序？
来自< a href = https://drafts.fxtf.org/css-masking-1/#the-clip-path rel = nofollow noreferrer>规范：
< blockquote>
计算出的值除 none以外的所有值都会导致创建堆栈上下文，就像 CSS不透明度对除1以外的值一样。
然后考虑绘画顺序：
- 所有位置，不透明度或变换后裔，按树顺序分为以下类别：
- 所有按树顺序排列的'z-index：auto'或'z-index：0'的后代。
对于具有'z-index：auto'的元素，将其视为已创建新的堆栈上下文，但是任何定位的后代和实际创建新堆栈上下文的后代均应视为父级堆栈上下文的一部分，不是这个新的。
对于那些具有'z-index：0'的对象，将其视为原子生成的堆栈上下文。
- 所有不透明度小于1的不透明子代，以树顺序创建一个
- 所有具有除非转换之外的转换的转换后代，以树顺序创建原子生成的堆叠上下文。
具有剪切路径是在步骤（8）绘制的，如果未设置位置，则会先绘制图像
- 对于所有其流入的，未定位的树状顺序的块级后代：如果元素是块，列表项或其他等效块...
如果添加 position：relative 对其进行成像，并将其置于步骤（8）之下，并且树顺序将决定使其位于剪切路径 e之上lement
这是具有 opacity 的相同代码，在这里您将具有相同的绘制顺序：
body {
padding：1em;
}
标头{
背景：＃a00;
不透明度：0.8;
}
h1 {
保证金：0;
padding：2em；
字体：300％；
颜色：白色；
text-align：center;
}
section {
背景：#ccc;
padding-top：5em;
margin-top：-5em;
}
img {
margin-top：-10em;
}
< header> ;
< h1>标题内容< / h1>
< / header>
< section>
< img src = https://via.placeholder.com/330/0000FF/808080 />
< / section>
相关：
许多其他属性的行为相同，因此必须在步骤中绘制元素（ 8）：
This has been asked before, but only where z-index is explictly defined in the CSS.
I am trying to use clip-path on a heading, but then pull up an image from within an element beneath this back over the top of that header. However, as soon as I define a clip-path on the header, the image (which should be higher up the stacking order as it appears later in the code) goes underneath the header:
body {
padding: 1em;
}
header {
background: #a00;
clip-path: polygon(0 0, 100% 0, 100% calc(100% - 5em), 0 100%);
}
h1 {
margin: 0;
padding: 2em;
font: 300%;
color: white;
text-align: center;
}
section {
background: #ccc;
padding-top:5em;
margin-top:-5em;
}
img {
margin-top: -10em;
}
<header>
<h1>Header Content</h1>
</header>
<section>
<img src="https://via.placeholder.com/330/0000FF/808080"/>
</section>
I would expect the image to be above the header. After playing around some more, I found that if I set position:relative on the image - it works:
body {
padding: 1em;
}
header {
background: #a00;
clip-path: polygon(0 0, 100% 0, 100% calc(100% - 5em), 0 100%);
}
h1 {
margin: 0;
padding: 2em;
font: 300%;
color: white;
text-align: center;
}
section {
background: #ccc;
padding-top:5em;
margin-top:-5em;
}
img {
margin-top: -10em;
position:relative;
}
<header>
<h1>Header Content</h1>
</header>
<section>
<img src="https://via.placeholder.com/330/0000FF/808080"/>
</section>
But why? What's happening here please and why does clip-path appear to affect the stacking order of elements later in the page?
From the specifcation:
A computed value of other than none results in the creation of a stacking context the same way that CSS opacity does for values other than 1.
Then considering the painting 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. For those with 'z-index: auto', 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. For those with 'z-index: 0' treat the stacking context generated atomically.
- All opacity descendants with opacity less than 1, in tree order, create a stacking context generated atomically.
- All transform descendants with transform other than none, in tree order, create a stacking context generated atomically.
The element with clip-path is painted at the step (8) and the image will be painted before if has no position set
- For all its in-flow, non-positioned, block-level descendants in tree order: If the element is a block, list-item, or other block equivalent ...
If you add position:relative to image it will be postioned and will fall under the step (8) and the tree order will decide making it above the clip-path element
Here is the same code with opacity where you will have the same painting order:
body {
padding: 1em;
}
header {
background: #a00;
opacity:0.8;
}
h1 {
margin: 0;
padding: 2em;
font: 300%;
color: white;
text-align: center;
}
section {
background: #ccc;
padding-top:5em;
margin-top:-5em;
}
img {
margin-top: -10em;
}
<header>
<h1>Header Content</h1>
</header>
<section>
<img src="https://via.placeholder.com/330/0000FF/808080"/>
</section>
Related:
Why does position:relative; appear to change the z-index?
Why can't an element with a z-index value cover its child?
Many other properties behave the same way and oblige your element to be painted at the step (8):
这篇关于为什么Clip-path（和其他属性）会影响DOM后面元素的堆叠顺序（z-index）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
