[css-transforms] Clarifying backface-visibility

We're working on implementing backface-visibility in Blink's new paint
architecture and have hit inconsistencies between implementations and the
spec:
https://drafts.csswg.org/css-transforms/#backface-visibility-property

Should backface-visibility create a stacking context?
Testcase: https://pr.gg/backfaceVisibilityStackingContextTest.html
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: https://pr.gg/backfaceVisibilityDescendantTest.html
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?
https://drafts.fxtf.org/compositing
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/pdr@chromium.org & Tien-Ren/trchen@chromium.org