Re: [css-transforms] Clarifying backface-visibility

The statement that blink and webkit create a stacking contexts is
incorrect. Blink and WebKit paint atomically which seems like a painting
bug, but they do not actually create a stacking context. Example:

On Thu, Feb 25, 2016 at 6:50 PM, Philip Rogers <> wrote:

> We're working on implementing backface-visibility in Blink's new paint
> architecture and have hit inconsistencies between implementations and the
> spec:
> Should backface-visibility create a stacking context?
> Testcase:
> Blink: yes, if backface-visibility: hidden.
> WebKit: yes, if backface-visibility: hidden.
> Gecko: no
> Edge: no
> Because WebKit and Blink have unfortunately had this behavior for a long
> time, it is likely that content now depends on the stacking context
> behavior.
> Which descendants does backface-visibility affect?
> Testcase:
> We've outlined some proposals below, although this is not exhaustive.
> Proposal A is our favorite but has issues such as the "3D plane" concept
> being poorly defined.
> Proposal A: backface-visibility only works on elements that create a 3D
> plane and applies to that plane.
> Proposal B: backface-visibility only works on flattening elements (i.e.,
> elements that create a sub 3D rendering context) and applies to every plane
> within that context.
> Proposal C: backface-visibility only works on elements that create
> stacking contexts, and affects the normal-flow descendants.
> Proposal D (as in the current spec): backface-visibility works on all
> individual elements, similar to how visibility works but with the used
> value determined by face orientation.
> How does backface-visibility interact with isolated groups as in
> compositing/blending?
> Blending with a transparent rect is different from not blending at all so
> we’re wondering whether hidden implies transparency or not drawing at all.
> Philip/ & Tien-Ren/

Received on Friday, 26 February 2016 21:39:21 UTC