[Bug 23015] New: Preserve-3d + backface visibility semantics need to be clarified

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23015

            Bug ID: 23015
           Summary: Preserve-3d + backface visibility semantics need to be
                    clarified
    Classification: Unclassified
           Product: CSS
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Transforms
          Assignee: smfr@me.com
          Reporter: shawnsingh@chromium.org
        QA Contact: public-css-bugzilla@w3.org
                CC: ayg@aryeh.name, cmarrin@apple.com, dino@apple.com,
                    dschulze@adobe.com, eoconnor@apple.com, smfr@me.com

Created attachment 1387
  --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1387&action=edit
Test case for Example 2

I have two examples that illustrate questions about preserve-3d and backface
visibility.

The first example can be found in the chromium bug here:
  https://code.google.com/p/chromium/issues/detail?id=224618

This developer's page has the following structure:

<div with perspective, but NOT preserve-3d>
   <div for face1 of cube, with backface visibility hidden>
   <div for face2 of cube, with backface visibility hidden>
   <div for face3 of cube, with backface visibility hidden>
   <div for face4 of cube, with backface visibility hidden>
   <div for face5 of cube, with backface visibility hidden>
   <div for face6 of cube, with backface visibility hidden>
</div>

According to spec, because the 6 faces are technically NOT in a 3d rendering
context, backface visibility must be checked against each layer's local
transform. This is awkward - the transform used to test backface visibility
(without perspective) is not the same one that is used to actually display the
layers (including perspective). As a result, if things are implemented
perfectly to spec, sometimes layers will disappear because to local transform
without perspective thinks the back-side of an element is visible.  But with
perspective, the front-side of the element is actually visible.

Some options how we could address this awkwardness:
 (1) leave the spec as-is, and the developer should actually be using
preserve-3d on the perspective container.
 (2) define that perspective transform creates a 3d rendering context, just the
same way that preserve-3d would.
 (3) make a special case that a perspective transform from a direct parent
should be included when testing backface visibility, even when not in a 3d
rendering context.


The second example is attached. This page illustrates a flip-card scenario when
the back side of the card is facing the camera.

On current versions of Chrome and Safari, this example actually renders the
child element of "front", even though it's back face is visible.  Should this
be considered a bug in the browsers?

I can see two different interpretations of spec:
(1) backface-visibility applies only to the element's itself.  The child
element in this example would test backface visibility using it's own local
transform (because it is not in a 3d rendering context), and ignore the
backface visibility of its ancestors. In this case, the child element would
awkwardly remain visible.
(2) Because there is no preserve-3d on the element, it implies that the
container element "flattens" its subtree before rendering.  In that case, the
child element gets hidden too when the parent's backside faces the camera.

It seems that Safari and Chrome both behave like #1, but I think it is more
intuitive for developers if it behaves like #2.

If that seems agreeable, then maybe we want to say something like this in the
spec:

"If the element specifies preserve-3d, then backface-visibility applies only to
the element itself and not its children.  If the element does not specific
preserve-3d, then it is interpreted that the entire subtree "flattens" to the
element, and backface-visibility would be used to determined if all the
flattened content (i.e. the entire subtree) should be displayed or not."

Thanks in advance for looking at these issues.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 19 August 2013 22:06:01 UTC