Re: [css-transforms] Handling combined opacity and preserve-3d

I agree with this approach by JoePea.

If anything, preserve-3d ought to be as its' namesake, preserving 3d being
more important than trying to preserve opacity.

I'm OK with opacity applying to its' own plane and popped planes escaping
that grouping, it makes sense as a web developer, rather than 3d not being
preserved on elements with preserve-3d (which would be surprising).




On Tue, 27 Sep 2016 at 20:26 /#!/JoePea <trusktr@gmail.com> wrote:

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