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

Hi Joe,

There's no need to resend your proposal. Also, we should www-style out
because crossposting makes things confusing.

It looks like a reasonable request but we can't start speccing it out until
we can specify and implement the basics of how planes are created.
Hopefully, Tien-Ren can work with Simon on that. (I'm happy to help out if
needed)


On Thu, Sep 29, 2016 at 8:31 PM, /#!/JoePea <trusktr@gmail.com> wrote:

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