转载

CSS Stacking Context里那些鲜为人知的坑

通常我们在学习/了解CSS的时候，并不会直接接触/了解到stacking context的规则，甚至在初学的时，仅仅接触到z-index、知道可以通过z-index控制元素显示的前后顺序，却常常由此碰到各式各样匪夷所思的bug，这两天我也趟了一次z-index浑水，搞明白了z-index扯出的这一系列stacking context坑。

什么是z-index

在W3C document里对z-index的解释是：

The z-index attribute lets you adjust the order of the layering of objects when rendering content.It means that CSS style rules allow you to position boxes on layers in addition to the normal rendering layer (layer 0). The Z position of each layer is expressed as an integer representing the stacking order for rendering. Greater numbers mean closer to the observer.

简言之我们通过z-index在layer 0上控制「已定位」元素的先后顺序，其值越大元素越靠近用户。#这里layer 0指代root节点即html元素

什么是Stacking Context

显然仅仅知道z-index的作用并不能解释现实中诸多怪异的CSS z-index定位表现，如同上一节中提到指代root节点的layer 0，在CSS中也可构造出与其相似的结构，这种提供z-index栈空间特性并影响子元素渲染顺序的结构，我们称之为stacking context。

怎样的CSS属性可以使element形成一个Stacking Context

满足下面规则的元素将会构造出一个 Stacking Context 结构：

root元素(html)
「已定位」元素（position: absolute or relative）且指定z-index值非auto的元素
flex item且指定z-index值非auto的元素
opacity小于1的元素
指定transform值非none的元素
指定mix-blend-mode值非normal的元素
指定filter值非none的元素
指定isolation值为isolate的元素
==特例 mobile webkit & chrome 22+，指定position: fixed的元素==
在will-change属性上指定值为上述列表任意属性的元素
指定-webkit-overflow-scrolling值为touch的元素

**注意除了前两条之外有如此多满足创建stacking context的条件，这也是造成诸多bug的源泉，比如opacity

Stacking Context有什么特性

stacking context可以嵌套
每个stacking context相对于兄弟元素是完全独立的，其内部规则不会影响到外部
每个stacking context元素都会被父stacking context当做一个元素施加stacking规则

对于一个stacking context内部的元素，如果这个元素没有形成stacking context，其z-index值是auto（但其实如果这个元素没有形成stacking context，z-index属性对这个元素的表现根本没有意义，我们可以理解为这个元素和其parent stacking context是一体的）。

我们通过给已定位元素（position: absolute or relative)指定z-index值以改变元素在其parent stacking context中Z轴的「相对偏移」量。这里的「相对偏移」指的是以parent stacking context为基准，相对于其它兄弟元素距离用户远近的顺序。

由于形成stacking context的元素其z-index属性并不对内部元素产生影响，因此其子元素以其（parent stacking context）为z-index相对基准点即z-index: auto，这些子元素的stacking context兄弟元素按照下面的远近顺序展示在屏幕：

远 ---------> 近

parent stacking context >> z-index > 非stacking context元素（z-index: auto） >> z-index >= 0 *注意在stacking context中的元素不会远于parent stacking context

非「定位」元素Stacking Context的特殊规则

先上一段极其容易产生困惑的代码（吐个槽w3ctech不支持embedded scripts够蛋疼）：

http://codepen.io/abruzzi/pen/yNJRKX

如上文提及，这里box3和box5通过opacity: .99创建了一个stacking context，但box3却覆盖在了box4之上，翻查W3C文档并没有这样一条规则定义stacking context元素默认在非stacking context元素之上；我们修改了box5的z-index属性为负值，box5依然在box6之上；我们又通过position: relative & z-index: -1创建了box7的stacking context，其表现却是正常的（话说回来，z-index: auto本身也无法形成stacking context，因此根本没有存在类似「stacking context元素默认在非stacking context元素之上」定义的意义）

在W3C文档的某个角落，我们可以究其原委：

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’.

简言之，如果一个元素不是通过「定位」(position: absolute or relative)实现了stacking context，它将会以z-index: 0（高于auto）被看待，因此无论如何更改非「定位」元素的z-index都是无效的。

虽然文档中只提到opacity less 1构成的stacking context被看做z-index: 0，但通过测试，可以发现其他非「定位」方式创建的stacking context拥有与opacity less 1一致的表现。

以上便是我对CSS stacking context中造成诸多匪夷所思现象原因的总结。

*注：下文内容与题目无关，仅为作者思路延展

什么是GraphicLayer

浏览器在解析渲染document时，内部的处理并未直接暴露给我们，其中很重要的结构就是Layers。在这些未暴露的步骤中，RenderLayers负责渲染整个DOM子树结构，GraphicLayers则负责渲染RenderLayers中的子树，GraphicLayer把所负责的子树作为textures（可以理解为内存间移动的位图）upload到GPU，以实现高速绘制，也因而可以大幅优化这些属性带来的动画效果。

包括opacity在内，这些可产生stacking context的属性和创建特殊GraphicLayers的属性（opacity, filter, transfrom3d等）都很相似，但某些属性却又无法吻合（例如2d transfrom），冥冥之中总觉得两者原理上有相似之处，能力有限，只好留一坑。