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

On Wed, Mar 4, 2015 at 9:21 PM Simon Fraser <smfr@me.com> wrote:

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

Yes, this is the same for chrome. Forcing thing2 to be composited with
will-change or similar causes it to appear.

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

I think Shawn had made a suggestion about what that subset might be here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23015

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