Re: [css-transforms] CSS3D breaks with opacity flattening

Here's an example using Famous Engine (http://github.com/famous/engine):

First, with opacity at the default value of 1.0, the "Famous Code" logo
moves back and forth and rotates:
http://jsfiddle.net/trusktr/spauv8fs/5

With opacity reduced, it breaks in Chrome 53:
http://jsfiddle.net/trusktr/spauv8fs/6

Famous Engine has the ability to mix WebGL with DOM, and this includes
opacity. This new behavior causes the DOM elements not to move in 3D space
the WebGL meshes.

First, here's a demo, with opacity at 1.0:
http://jsfiddle.net/trusktr/spauv8fs/7

The, with opacity at 0.7:
http://jsfiddle.net/trusktr/spauv8fs/8

What you are supposed to see is a DOM element and a WebGL Mesh that both
seem to intersect with the pink DOM-based background (the implementation is
not perfect yet...). In the second fiddle (spauv8fs/8) the "Famous Code"
logo appears not to move any more while the WebGL mesh continues to move.

There is a bug in the WebGL renderer which I believe may be due to changes
in WebGL, but the WebGL part of those examples is supposed to be
transparent as well.

I myself am working on a new implementation of DOM + WebGL, and it allows
application of opacity. This change in Chrome 53 completely breaks how that
is supposed to work. I don't have an online demo yet...

I would say let's definitely consider undoing the changes to the spec so
that flattening does not happen when applying an opacity to 3D DOM
elements. The reasoning is not just to prevent breaking apps, but because
the new behavior simply doesn't make sense as far as 3D goes.

*/#!/*JoePea

On Wed, Sep 14, 2016 at 6:23 PM, /#!/JoePea <trusktr@gmail.com> wrote:

> > Do you have public web content that is broken by this change?
>
> Here's one, open in Firefox and Safari, then see how it's broken in Chrome
> 53: https://mightydevs.com
>
> In Chrome 53 you'll notice that the letters are all smushed onto a flat
> plane, and when the opacity of the whole thing reaches 1 the letters
> instantly go into their actual positions in 3D space. In Firefox and Safari
> you'll notice that it works properly, and the letter won't be flattened at
> the beginning, which is the expected behavior.
>
> */#!/*JoePea
>
> On Wed, Sep 14, 2016 at 5:33 PM, Chris Harrelson <chrishtr@google.com>
> wrote:
>
>> Here is more context on the change in Chrome 53, including some
>> information on why.
>>
>> blink-dev thread
>> <https://groups.google.com/a/chromium.org/forum/#!search/blink-dev$20opacity$20flattening/blink-dev/eBIp90_il1o/9q3M0ww2BgAJ>
>>
>> https://www.chromestatus.com/features/5671480339726336
>>
>> www-style thread for reference: http://lists.w3.org
>> /Archives/Public/www-style/2016May/0239.html
>>
>> On Wed, Sep 14, 2016 at 5:24 PM, Simon Fraser <simon.fraser@apple.com>
>> wrote:
>>
>>>
>>> On Sep 14, 2016, at 5:09 PM, /#!/JoePea <trusktr@gmail.com> wrote:
>>>
>>> > But are they doing correct group opacity?
>>>
>>> The behavior in Chrome 52, Firefox, and Safari 9 is correct, yes. The
>>> implementation and wording isn't as important as the results, and the
>>> result in Chrome 53 is not correct.
>>>
>>> Actually, Chrome 52 and Safari behavior aren't doing correct group
>>> opacity. Testcase at <http://smfr.org/css/transform
>>> s/opacity-preserve-3d.html>. You should not see the darkening where the
>>> layers overlap.
>>>
>>> Chrome 53 fixes this, but as you say, this can break web content. It's
>>> possible that we'll have to revert this spec change due to web compat
>>> issues.
>>>
>>> Do you have public web content that is broken by this change?
>>>
>>> Simon
>>>
>>>
>>> On Sep 14, 2016 5:08 PM, "/#!/JoePea" <trusktr@gmail.com> wrote:
>>>
>>>> Pardon that I don't know the spec terminology, I'm just iterating what
>>>> the proper behavior is (what we see in Chrome 52).
>>>>
>>>> For reference, try first demo I linked in the Chrome issue, and nite
>>>> that it is now broken in Chrome 53, but works fine in Firefox and Safari 9.
>>>>
>>>> We can't be breaking the web like this, and we can't be introducing
>>>> behaviors that don't make sense from a 3D stand point.
>>>>
>>>> On Sep 14, 2016 5:04 PM, "/#!/JoePea" <trusktr@gmail.com> wrote:
>>>>
>>>>> I see what you're saying: you're just re-iterating the spec, whose
>>>>> design is flawed.
>>>>>
>>>>> The behavior should be just as it were before Chrome 53 was released.
>>>>> It's all works nicely in Chrome 52.
>>>>>
>>>>> How you will word that in the spec is a different issue, and all I'm
>>>>> saying is that Chrome 52 exhibits proper behavior, as do current Firefox
>>>>> and Safari.
>>>>>
>>>>> Chrome 53 follows this flawed spec, and is therefore broken.
>>>>>
>>>>> On Sep 14, 2016 4:58 PM, "Simon Fraser" <simon.fraser@apple.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Sep 14, 2016, at 4:24 PM, /#!/JoePea <trusktr@gmail.com> wrote:
>>>>>>
>>>>>> > Authors can work around this by applying opacity on their leaf
>>>>>> elements individually, or by using rgba() colors etc.
>>>>>>
>>>>>> That's not a valid workaround because in many cases there needs to be
>>>>>> opacity on parent elements.
>>>>>>
>>>>>> For example, imagine a game object which is a vehicle. The parent
>>>>>> contains sub children positioned relatively to the parent (using tranforms)
>>>>>> in order to place the doors, wheels, and body of the vehicle (maybe it is a
>>>>>> truck, car, or motorcycle). Now, imagine in this game that the cars are
>>>>>> alive (like in the movie "Cars", and one of them is a ghost. To achieve
>>>>>> this, we apply an opacity to the parent element, which makes the whole car
>>>>>> transparent. Or, imagine that there is a "ghost" car in a racing game in
>>>>>> order to show where you were during your last attempt, so that you can
>>>>>> attempt to beat your last time. We apply opacity to the whole car, and
>>>>>> expect for thecar to remain 3D, not be flattened.
>>>>>>
>>>>>> In cases like with the car examples, we cannot simply apply opacity
>>>>>> to leaf-most elements. Furthermore, rgba() colors apply only to things like
>>>>>> background, border, text colors, etc, but not to the whole element, so
>>>>>> that's not a workaround.
>>>>>>
>>>>>> The only workaround is to NOT use nested elements, but that prohibits
>>>>>> the use of CSS transform caching that we get with the nested approach. It
>>>>>> is imperative that the nested approach works along with opacity without
>>>>>> flattening, otherwise this change is detrimental to 3D in the web, and is
>>>>>> completely unintuitive. Making a 3D object flat because it has opacity
>>>>>> simply does not make sense (it doesn't matter if that's what spec says).
>>>>>>
>>>>>> For reference, the "nested" approach is the form of CSS3D that
>>>>>> IE10/11 does not support, with preserve-3d.
>>>>>>
>>>>>> Grouping is fine, as it makes much sense for all children to inherit
>>>>>> the opacity level and have it multiplied with their own opacity (just like
>>>>>> how positional transformations work), but additional flattening is simply
>>>>>> not a good design choice.
>>>>>>
>>>>>>
>>>>>> Unfortunately you can't have one (grouping) without the other
>>>>>> (flattening), at least with the 3D implementation in WebKit, and I suspect
>>>>>> other UAs too. The way that preserve-3D works is to hoist descendant layers
>>>>>> up to effectively become siblings of their parent/ancestor elements in the
>>>>>> same 3D-rendering context, so they call get positioned and depth-sorted in
>>>>>> the same 3D coordinate space. There's no way you can do group opacity in
>>>>>> this model without rendering some subtree of transformed elements into a
>>>>>> texture (which is flattening).
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>> Please consider modifying the spec so that opacity does not destroy
>>>>>> 3D scenes. Also please consider the same for mix-blend-mode, and similar
>>>>>> effects.
>>>>>>
>>>>>> Best regards,
>>>>>> - Joe
>>>>>>
>>>>>> */#!/*JoePea
>>>>>>
>>>>>> On Wed, Sep 14, 2016 at 3:58 PM, Simon Fraser <simon.fraser@apple.com
>>>>>> > wrote:
>>>>>>
>>>>>>> On Sep 14, 2016, at 3:51 PM, /#!/JoePea <trusktr@gmail.com> wrote:
>>>>>>>
>>>>>>> The following is a big problem for people making 3D scenes, and I
>>>>>>> really think this needs to be rethought:
>>>>>>>
>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=646993
>>>>>>>
>>>>>>> Not only does it break existing apps, but it also makes it difficult
>>>>>>> to create 3D HTML scenes that involve opacity. The intuitively expected
>>>>>>> behavior (as listed in that issue) is that opacity applies to children but
>>>>>>> does not cause unintuitive flattening.
>>>>>>>
>>>>>>> If browsers follow the latest spec, then we are making it more
>>>>>>> difficult to do and discouraging 3D in the web, which I don't think is what
>>>>>>> we want.
>>>>>>>
>>>>>>> The faulty part of the spec is here: https://drafts.csswg.org
>>>>>>> /css-transforms/#grouping-property-values
>>>>>>>
>>>>>>> It states that opacity should cause grouping, which is what causes
>>>>>>> the flattening.
>>>>>>>
>>>>>>> Is there an alternative way to achieve opacity less than 1.0 without
>>>>>>> flattening of 3D scenes, that I may have missed? Unless there's an
>>>>>>> alternative, this behavior is a bad idea for authors of 3D HTML scenes.
>>>>>>>
>>>>>>>
>>>>>>> CSS opacity is defined to be "group opacity", which means rendering
>>>>>>> everything into a bitmap, and then paint that bitmap with alpha. This gives
>>>>>>> a different result to painting individual elements with opacity, when those
>>>>>>> elements overlap.
>>>>>>>
>>>>>>> The CSS transforms spec is conforming to this group opacity
>>>>>>> behavior, which, in implementations, requires flattening at rendering time.
>>>>>>>
>>>>>>> Authors can work around this by applying opacity on their leaf
>>>>>>> elements individually, or by using rgba() colors etc.
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>
>