Re: [css-transforms] Rendering descendent content of backface-visibility: hidden elements

On Mar 4, 2015, at 4:22 PM, Matt Rakow <marakow@microsoft.com> wrote:
> 
> Hi all,
> 
> For an element that is backface-visibility: hidden and is transformed such that it is backfacing, what (if any) of its descendant content should be rendered?  Consider http://jsfiddle.net/4qja8tf3/ -- this shows 3 similar scenes.

The jsfiddle needs -webkit-backface-visibility: hidden; for testing in WebKit.

> The first one is front-facing so each element is visible.  No issues here of course.
> 
> The second rotates the wrapping "world" div with backface-visibility: hidden, but does not utilize preserve-3d.  Naturally the "world" div is not drawn in this case, but Chrome and FF differ on whether the descendant content is drawn.  Chrome draws only the descendant content with a transform (green div), whereas FF draws none of it.
> 
> The third is the same as the second, but utilizing preserve-3d.  In this one Chrome still only draws the transformed descendant content (green div), whereas FF draws both transformed and untransformed descendant content (green and red divs).
> 
> Based on a strict reading of the spec as currently written, I think both the green and red elements would be visible in all 3 scenes.  Backface-visibility isn't inherited, so both the green and red elements are backface-visible -- this implies they should be visible regardless of how they or their ancestors have been transformed.  However, I'm not sure this is the most desirable behavior since it would make it difficult for an author to hide a complex scene in its entirety.  One alternative that I think I prefer would be to always hide all elements that are descendants of an element which is hidden due to backface-visibility: hidden.
> 
> I definitely feel the disparity between transformed and untransformed elements seen in Chrome is unintuitive.  And I'm not a huge fan of the disparity between preserve-3d and non-preserve-3d scenarios.  I'd be interested to hear other options or opinions on this.

I know that the WebKit behavior is just a side-effect of which elements get composited (i.e. mapped to composited textures), and I suspect that Blink still shares much of this code.

I think the spec needs to be reworded to say that backface-visibility affects an element and some subset of its descendants, but I’m not sure how to define that subset. This should probably share wording with the (as yet unwritten) section on how 3d-transformed elements intersect with other non-transformed or 2d-transformed elements that share the same 3D rendering context.

Conceptually, if a "backface-visibility: hidden” element has a 3d-transformed descendant which shares the same 3d-rendering context, then that descendant’s visible should depend on the descendant’s accumulated transform, and should not be hidden by virtual of it’s ancestors backface-visibility. Maybe that’s the only case where a descendant “pops out” of an ancestor's backface-visibility:hidden.

Simon

Received on Thursday, 5 March 2015 02:18:21 UTC