- From: François REMY <francois.remy.dev@outlook.com>
- Date: Thu, 5 Mar 2015 18:28:08 +0100
- To: "'Matt Rakow'" <marakow@microsoft.com>, <www-style@w3.org>
± 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