Bug 23015 - Preserve-3d + backface visibility semantics need to be clarified
Preserve-3d + backface visibility semantics need to be clarified
Status: NEW
Product: CSS
Classification: Unclassified
Component: Transforms
unspecified
PC All
: P2 normal
: ---
Assigned To: Simon Fraser
public-css-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-19 22:06 UTC by Shawn Singh
Modified: 2013-09-25 20:57 UTC (History)
6 users (show)

See Also:


Attachments
Test case for Example 2 (2.00 KB, text/html)
2013-08-19 22:06 UTC, Shawn Singh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shawn Singh 2013-08-19 22:06:00 UTC
Created attachment 1387 [details]
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.
Comment 1 Dirk Schulze 2013-09-25 20:57:40 UTC
(In reply to Shawn Singh from comment #0)
> Created attachment 1387 [details]
> Test case for Example 2

I think we should create two bug reports to discuss this.

> 
> 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.
> 

I am creating a test suite that exactly checks the different behaviors across browsers on preserve-3d and flatten. You can find the repository on github under

http://adobe-webplatform.github.io/transform-tests/comparison.html

The tests still need clean up and quite some corrections. Also, expected results fully depend on the outcome of the discussions.

Your example touches the last test cases with blue and yellow. You'll see that the problem is not just related to perspective but the interpretation of 'flatten' on the transform-style property. In fact all tests test edge cases of transform-style  with certain other settings like perspective.

I encourage you to transform your tests to ref-tests in the format of the CSS WG. See http://wiki.csswg.org/test/reftest

That makes it easier to compare results and makes it possible to reuse the tests  for spec testing.