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

> So, this would only be for opacity and not for any other effects?

For any backdrop-interacting properties including opacity.

In the case of opacity, it can sometimes be desirable to have it multiply
down the tree, which is why I was thinking of the `blend-3d` idea.

But multiplication down the 3D scene graph possibly only makes sense with
opacity, but not with (for example) mix-blend-mode, and definitely not with
properties like clip. So I think the property may be specific for opacity,
`opacity-mode` or similar.

```css
div {
  opacity-mode: auto; /* defaults to "single" mode. */
}

div {
  opacity-mode: single; /* apply only to the plane and grouped 2D items,
not popped-out 3D planes. */
}

div {
  opacity-mode: multiply; /* apply to the plane and grouped 2D items,
multiply to popped-out planes. Along the way, opacity applies to each plane
including 2D grouped children. */
}
```

​The following properties are currently listed as grouping (and flattening):

   - *overflow*: any value other than visible.
   - *opacity*: any value less than 1.
   - *filter*: any value other than none.
   - *clip*: any value other than auto.
   - *clip-path*: any value other than none.
   - *isolation*: used value of isolate.
   - *mask-image*: any value other than none.
   - *mask-border-source*: any value other than none.
   - *mix-blend-mode*: any value other than normal.
   ​

(
​I don't see backdrop-filter, was that supposed to be there?).

They would
​remain grouping, but only grouping (i.e. keeping-flat) the 2D items on the
target element's plane. In 3D contexts, 3D children would escape from the
grouping into their own planes in the 3D space.

This makes much more intuitive sense when you consider the end-developer's
ability to write 3D scenes, and is backwards compatible with the ancient 2D
APIs of the web, and easier to reason about in terms of the HTML structures
that 3D developers will write.

If consensus can be made on how to treat cases like what
​​ <https://lists.w3.org/Archives/Public/public-fx/2016JulSep/0071.html>
Tien mentions
<https://lists.w3.org/Archives/Public/public-fx/2016JulSep/0071.html> with
stacking context
​s​
​ (I agree with what he's proposing, that
the children should be popped into a new plane
​ in edge cases like `transform:translateZ(0)` and not be merged into the
parent plane)​
, then we can be ready to spec better behavior
​that is similar to what I'm mentioning.

​But, even if Tien's proposals are not accepted, then the grouping
*still* doesn't
need to apply whenever a child is popped into a new plane, although it
would be very confusing when the 3D child is merged onto the parent plane
during `transform:translateZ(0)`​ because it will suddenly have the same
effects as the group, so I really think keeping it popped out is very
ideal. Let's take Tien's suggestions on this one.

- Joe​

P.S., Leaving overflow:hidden as is would be ideal because it gives us a
specific method of creating a new 3D context within an existing 3D context,
and I don't think that making a new 3D context is something that we want to
be able to do purely with CSS styling -- I think having to make it explicit
in markup is nice for this (i.e. instead of applying overflow:hidden onto a
parent node in the current 3D context, which would flatten children into
the new 3D context, we would add a child into the parent and set overflow
on it, make our new scene inside there, then other elements that should be
in the outer 3D context would be sibling to the new 3D context).

```html
<style>
    .scene {
        overflow: hidden;
        perspective: 800px;
    }
    .node, .scene {
        transform-style: preserve-3d;
    }
</style>
<div class="scene">
    <div class="node" style="transform:matrix3d(...)">

        <!-- New 3D context inside the outer 3D context. -->
        <div class="scene">
            <div class="node" style="transform:matrix3d(...)"></div>
        </div>

        <div class="node" style="transform:matrix3d(...)"></div>

    </div>
</div>
```

*/#!/*JoePea

On Wed, Sep 28, 2016 at 8:24 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> On Wed, Sep 28, 2016 at 7:29 AM, Nexii Malthus <nexiim@gmail.com> wrote:
>
>> 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).
>>
>
> So, this would only be for opacity and not for any other effects?
> This new behavior will make specs inconsistent and confusing for authors.
> It will also be difficult to implement as this special-casing needs to
> happen all over the browser's codebase which will lead to bugs.
> Let's not add workarounds, especially if re-arranging elements will give
> you the exact same effect.
>
>
>> 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
>>>
>>
>