Re: [css-transforms] CSS3D breaks with opacity flattening

On Thu, Sep 22, 2016 at 1:03 AM, Tien-Ren Chen <trchen@chromium.org> wrote:

> On Wed, Sep 21, 2016 at 12:02 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > translateZ() and z-index should
> > work similarly, as they're doing the same thing.
>
> I don't agree with you. IMO a 3D transform should pop the subtree to a
> new plane if inside of a 3D context. e.g.
>
> <style> div { transform-style: preserve-3d; } </style>
> <div style="position:relative; z-index:0;">
>     Plane A
>     <div style="transform:translateZ(0);">Plane B</div>
>     <div style="z-index:1;">Plane A too</div>
> </div>
>
> Should be treated the same as:
>
> <style> div { transform-style: preserve-3d; } </style>
> <div style="position:relative; z-index:0;">
>     Plane A
>     <div style="z-index:1;">Plane A too</div>
> </div>
> <div style="transform:translateZ(0);">Plane B</div>
>
> This will avoid having to deal with the transition between
> translateZ(-epsilon) / translateZ(0) / translateZ(epsilon) in case of
> an animation, which incurs a huge runtime cost because every stacking
> context after a transformed child will need to be cached separately.
>
> In my mental model, this is how a compositing tree should look like:
>
> Output = StackingContext
> StackingContext = NormalFlowBackground + Child* + NormalFlowForeground
> + Child* [#1]
>      || flatten( 3dContext )
>      || grouping_property( StackingContext )
> Child = StackingContext || PseudoStackingContext
> PseudoStackingContext = NormalFlowBackground + NormalFlowForeground
> 3dContext = Plane*
> Plane = StackingContext, Matrix44
>
> Note #1: Operator+ is our typical src-over. In case of CSS blending,
> replace operator+ with appropriate operator.
>
> Basically each StackingContext physically is an array of RGBA pixels.
>
> Combined with a Matrix44 give each pixel a depth, each Plane
> physically is an array of RGBAD pixels. Flattening operation takes a
> list of planes, and src-over (or blend) each pixels depth-sorted  (in
> case of a tie, stacking context order is used to break the tie.). The
> actual implementation will most likely do polygon splitting, as
> performing a sort on each pixel over a number of planes would be
> prohibitively expensive.
>
> And I would spec the painting order of elements with this decision tree:
> ---- z-index: auto ---
> 1. An element paints as the normal flow of the current (pseudo)
> stacking context if the element has z-index:auto and position:static.
> 2. An element establishes a pseudo stacking context if it has
> z-index:auto and position other than static. This new pseudo stacking
> context sorts into current stacking context as if z-index is 0.
> --- non-auto z-index, with no 3D[#2] transform ---
> 3. An element establishes a stacking context if it has non-auto
> z-index and no 3D transform. This new stacking context become the
> current stacking context and sorts into previous stacking context by
> z-index value.
> --- 3D transformed ---
> 4. An element establishes a stacking context if it has 3D transform
> and both itself and its containing block have transform-style:flat.
> The depth part of the transform is discarded and behave like case 3.
> 5. An element establishes a plane and a stacking context if it has 3D
> transform and its containing block has transform-style:preserve-3d.
> This new plane joins the current 3D context, and the new stacking
> context becomes the root stacking context of the new plane. The
> z-index is unused except for tie breaking.
> 6. An element establishes a 3D context, a plane and a stacking context
> if it has transform-style:preserve-3d and its containing block has
> transform-style:flat. This new 3D context will flatten its planes and
> become a child stacking context that sorts into current stacking
> context by z-index value. This new plane joins the new 3D context, and
> the new stacking context becomes the root stacking context of the new
> plane. [#3]
>
> Note #2: There is a discrepancy in the definition of 3D-ness of
> transforms. Firefox & Edge uses the computed local matrix. Blink &
> WebKit see whether a 3D operation is used in the property.
> Note #3: We can see in this case actually two stacking contexts are
> created. It is unspecified in the current spec whether grouping
> properties apply to the flattened output or the root stacking context
> of the new plane. Behavior is inconsistent across vendors.
>

Hi Tien-Ren,

this is great feedback for the interaction between z-index and 3d
transforms.
Can you file this an issue on https://github.com/w3c/csswg-drafts?