- From: Philip Rogers <pdr@chromium.org>
- Date: Thu, 25 Feb 2016 18:50:51 -0800
- To: "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAJgFLLuRnYT2Pk_At9Td-DxvOUUW5we5S1Tgc9wYoXitct-1XA@mail.gmail.com>
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
Received on Friday, 26 February 2016 02:51:41 UTC