- From: /#!/JoePea <trusktr@gmail.com>
- Date: Tue, 27 Sep 2016 12:25:10 -0700
- To: public-fx@w3.org, "www-style@w3.org" <www-style@w3.org>, Matt Woodrow <mwoodrow@mozilla.com>, Tien-Ren Chen <trchen@chromium.org>
- Message-ID: <CAKU1PAXZCopvkNk6_weYVqQC1HLkY-NR1rA-R6-WLPqRHVcLkQ@mail.gmail.com>
> > What is the expected behaviour when transform-style:preserve-3d and > opacity are combined on a single element? > The current working draft [1] makes no mention of what to do. > I wrote a test to check the behaviours of various browsers [2] and it > looks like both Blink and Webkit apply the opacity to each of the > preserve-3d 'leaves' instead of applying it as a group. > Gecko flattens that subtree to apply the opacity as a group, and in > currently Nightly we make a better attempt to sort what remains. > The current editors draft [3] also requires flattening, but I don't > think that's going to be web compatible, as we've already found websites > that are using this [4]. > I think it's worth updating the working draft to spec the Blink/Webkit > behaviour, since the editors draft is a big change and unlikely to be > finished quickly. I'll happily fix Gecko to match this behaviour. Let's fix the spec, please! It is obvious that new 3D scenes are not the same as 2D scenes rendered according to specs that are decades old. Opacity does not need to be absolutely grouping when in a 3D context, it only needs to group the content which remains on the 2D plane of the element with the opacity property, and not the 3D children that are popped out into 3D space. In Tien's email here <https://lists.w3.org/Archives/Public/public-fx/2016JulSep/0071.html>, he asks if a plane with translateZ(0) should be popped into it's own new plane. I believe yes. And then, once that's solved, opacity (and other backdrop-interacting properties) can apply only to the plane that they are applied to, almost as if they are still grouping, but that 3D popped-out content on new planes escape the grouping and are not affected. Additionally, I've proposed that the end-developer should have control over this: ```css div { blend-3d: auto; /* Defaults to "single" which does not multiply down 3D descendant elements in a 3D context. */ } div { blend-3d: single; /* does not multiply down 3D descendant elements in a 3D context. */ } div { blend-3d: multiply; /* multiplies down 3D descendant elements in a 3D context, and perhaps it stops at the next 3D descendant element that has "blend-3d: single". */ } ``` This would let developers choose what behavior they want, and does not break CSS principles like the new behavior does (because the new behavior requires markup changes or DOM restructuring in order to achieve the desired visual style). At the very least, if you guys decide that such a property like `blend-3d` is not to be introduced, then just apply opacity onto the plane that opacity is applied to, and let 3D content escape the grouping. This would still be great because it does not break CSS principles, and the end-developer can still manually multiply and apply opacities to descendant 3D elements. > > Thanks! > - Matt > > [1] http://www.w3.org/TR/css-transforms-1/#transform-style-property > [2] http://people.mozilla.org/~mwoodrow/preserve3d-opacity.html > [3] https://drafts.csswg.org/css-transforms/#grouping-property-values > [4] http://lacigrona.com/carta/comida/ */#!/*JoePea
Received on Tuesday, 27 September 2016 19:26:26 UTC