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

± De : Matt Rakow [mailto:marakow@microsoft.com]
± 
± 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 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.
± 
± Thanks,
± -Matt

Hi,

I can't tell you more about the spec than you probably know but, based on my intuitive understanding of 3D transforms, I would say the Firefox behavior makes sense to me.

If you have an element with "no preserve-3d", its descendants do not exist in the 3D space. They are drawn on the plane of the said container element. If that element is back-facing and doesn't render from the back, everything is gonna be hidden. That's what you see in Firefox.

If you set "preserve-3d" on the element, its descendents exist on their own in the 3d space; the fact they are descendant of some other element doesn't have any impact on their rendering once they're positioned in 3d space. Of course, they are back-facing because they're positioned on a plane that's back-facing but, as you said, they should be drawn because " backface-visibility" isn't inherited to "hidden" on them. Again, that's what Firefox does.

I guess this is the reasoning the implementor at Mozilla went through, too.

Received on Thursday, 5 March 2015 17:28:40 UTC