Chrome 53's changes to CSS opacity break 3D transforms.

[trusktr]

Check out this nasty problem Chrome 53 introduced (by following a flawed spec), which breaks ReFamous if you want to use opacity on a parent node that contains any children:

https://bugs.chromium.org/p/chromium/issues/detail?id=646993

Please leave a comment there to help persuade them to take back the changes.

You can reproduce the problem with ReFamous by make a parent node, adding a bunch of child nodes with arbitrary X,Y,Z positions, then apply an opacity to the parent node. In the parent node and child node make sure you have a DOMElement so that the result is a nested DOM structure when you inspect element.

What you'll see happen is that the child nodes will be flattened into a plane. This is a really bad design idea from the CSS-transforms specification.

When using mixed mode, then it will cause a nasty bug where the DOMElements are flattened, and the WebGL meshes are not.

[CompSciFutures]

Oh dear. Thanks for the heads up.

On 15 Sep 2016, at 11:45 AM, Joseph Orbegoso Pea notifications@github.com wrote:

Check out this nasty problem Chrome 53 introduced (by following a flawed spec), which breaks ReFamous if you want to use opacity on a parent node that contains any children:

https://bugs.chromium.org/p/chromium/issues/detail?id=646993

Please leave a comment there to help persuade them to take back the changes.

You can reproduce the problem with ReFamous by make a parent node, adding a bunch of child nodes with arbitrary X,Y,Z positions, then apply an opacity to the parent node. In the parent node and child node make sure you have a DOMElement so that the result is a nested DOM structure when you inspect element.

What you'll see happen is that the child nodes will be flattened into a plane. This is a really bad design idea from the CSS-transforms specification.

When using mixed mode, then it will cause a nasty bug where the DOMElements are flattened, and the WebGL meshes are not.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[trusktr]

@Aprender Check out these two Famous 0.7.1 fiddles I made, it shows the problem. The only difference between the two examples is that in the second one I have set opacity to 0.7 on the rootNode:

• http://jsfiddle.net/trusktr/spauv8fs/7
• http://jsfiddle.net/trusktr/spauv8fs/8

In the second example, since opacity is set to 0.7, the DOMElement is flattened into the pink background DOMElement, and appears not to move anymore.

Do you mind sending an email to public-fx@w3.org with "[css-transforms]" in the subject, as well as commenting at https://bugs.chromium.org/p/chromium/issues/detail?id=646993, confirming that it is a problem?

[CompSciFutures]

Certainly will if it's affecting what I'm doing, just spinning up a new VM now to check. I've just msgd @dmvaldman on Gitter to flag it with him as well.

[CompSciFutures]

@truskr, so when you say flatten, it means the transformation matrix is the identity matrix?

[trusktr]

@Aprender No, it just means that although the CSS transform properties are applied to the eventual DOM elements that ReFamous is rendering in the DOM, those elements will not obey their transforms, and will be flattened into the scene. I mean, although the CSS transform property is applied by ReFamous, the HTML engine will not transform the elements are we expect while opacity is less than 1.0.

Here's another example: look at this in Chrome 53+, and then look at it in Firefox 47- or Safari 9: https://mightydevs.com

In Chrome 53+ you'll notice that while the letters are fading in, they appear to be flattened onto a single plane. In Firefox and Safari you'll notice that while the letters are fading in they will remain in their cloud formation as expected. In Chrome 53, once the opacity reached 1.0, then the letters will suddenly appear to jump into formation.

The behavior in Firefox and Safari is the correct behavior.

@dmvaldman It would be highly appreciated if you could voice your opinion about this in the above Chrome issue, and in public-fx@w3.org mailing list. From what I can tell, Samsara isn't using the nested-dom strategy yet, so this issue won't affect Samsara.

For reference, here is the public-fx discussion so far: https://lists.w3.org/Archives/Public/public-fx/2016JulSep/subject.html (Look under the topic "[css-transforms] CSS3D breaks with opacity flattening").

[trusktr]

Here's a really good example. Try the following in all the browsers, then note how in Chrome 53 the box will be flattened when you press the button: http://codepen.io/jpanter/pen/PGqJOm?editors=1100

When the button is clicked, an opacity animation is added to the box. In Chrome 53, this causes the HTML engine's renderer to flatten the sides of the box into a flat plane. In other browsers, the box will remain a box, and it will become transparent as expected.

[trusktr]

@gadicc, would love your input on this too!

[CompSciFutures]

Okay I get it - that's just madness.

[dmvaldman]

Need to think about this a bit more. I welcome the fact that in the flattened version, the layering is correct. Chrome was bad at this before, as it would use DOM order instead of translateZ order post-flattening (like if {overflow:hidden} was applied).

I can see why they did this: defining opacity on a "group" that isn't flattened doesn't really make much sense. The only sense it could make is if you really just meant to define each item of the group with that same opacity. Consider a group that is two planes which intersect at some angle. There are really 2 opacities at play: one when the planes are overlapping, and one where they aren't. There is no opacity for the "group" that is applied once. There is an opacity for each part, which is later composited.

Library authors can solve for this change simply by passing the opacity down to the leaves of their scene graphs. An opacity of .5 for a group of things, just means the opacity for each thing gets multiplied by .5. Everything will then work as intended without changing the API.

[dmvaldman]

Reading the discussion, the last post (at this time) by Simon is dead on

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.

[trusktr]

@dmvaldman

Library authors can solve for this change simply by passing the opacity down to the leaves of their scene graphs.

That's impossible in some cases.

f.e. the following is a hypothetical 3D scene where each item is translated and rotated (using matrix3d) relative to it's parent (for convenience and rather than having to calculate world transforms manually from a virtual tree and having to apply the results to a non-nested DOM structure like in Samsara):

<style>
    ...
    div {
        transform-style: preserve-3d;
    }
    ...
</style>

...
<div style="transform: matrix3d(...)">
    this is rendered content

    <div style="transform: matrix3d(...)">
        this is rendered content

        <div style="transform: matrix3d(...)">
            this is rendered content
        </div>
    </div>
</div>
...

You here, and people in the public-fx thread, propose that in order to make everything transparent we can apply opacity to leaf-node elements directly.

1. That is impossible in the above example without changing the markup to convert the scene into a flat structure instead of being nested, otherwise the whole object will be flattened as soon as the parent-most div has opacity applied to it.
2. The individual opacities will be inherited and multiplied anyways, according to new spec.
3. Someone who has no access to the HTML and can only modify the CSS is out of luck, because this requires a markup change.
4. After making the markup change (i.e. converting to the non-nested approach for CSS3D), the opacities will no longer be multiplied by the HTML/CSS engine, which will require manual JavaScript in order to do the multiplication.
5. Having to change the markup changes the structural meaning that is being conveyed, and possibly changes the semantical meaning of the content as far as spiders, crawlers, and accessibility tools are concerned.
6. Library authors like me, who depend on (and prefer) the nested approach of defining 3D scenes using preserve-3d, and who are defining custom elements that can contain content just like the rendered content in the above examples, will now have to render to a separate root element where all the 3D objects are non-nested, all transforms are multiplied manually rather than by the HTML/CSS engine, and all opacities are multiplied manually rather than by the HTML/CSS engine.
7. Users of libraries made by those authors will not be able to place content into the custom elements in a reliable way. It destroys CSS selection in the following ways:
   1. If the original content remains (by design of the library) in the custom elements and content is cloned into the new non-nested scene structure, then if the user modifies the original content they will not modify the have successfully modified the content in the rendered non-nested structure. A library could try to solve this by using MutationObserver and copying all changes over, but this does not solve the problem that the user may have a reference to a completely different element than expected so normal JavaScript properties assigned to the reference will not transfer over. CSS selection that relies on the DOM structure that the library user has written will not work.
   2. If the content is moved (by design of the library) into the new non-nested scene, then there at least are only one reference to the user's content, but the user will still have a hard time with selectors.
   3. In either case, the user will have to start using id="" everywhere when not necessary.

All in all, these changes to Opacity just make things really ugly.

[trusktr]

@dmvaldman If you have a chance, I'd like to propose that you make an experimental branch of Samsara and try rendering nested DOM structures using preserve-3d (similar to what Famous Engine did, and what I'm doing).

I guess if you did that, and your engine still only renders content on the leaf nodes, then it will be no problem.

But, in my case, my HTML API can be used like the following (similar result as the previous example):

<motor-scene>
    <motor-node position="..." rotation="...">
        this is rendered content

        <motor-node position="..." rotation="...">
            this is rendered content

            <motor-node position="..." rotation="...">
                this is rendered content
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

What then happens is that the position/rotation/etc attributes are composed into a matrix, then applied to the same motor-node elements via transform: matrix3d(). This means that the content (f.e. this is rendered content) are rendered in the scene just like normal HTML.

However, if I want to apply an opacity to the second motor-node, f.e.

<motor-scene>
    <motor-node position="..." rotation="...">
        this is rendered content

        <motor-node position="..." rotation="..." opacity="0.5">
            this is rendered content

            <motor-node position="..." rotation="...">
                this is rendered content
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

then the inner-most motor-node will be suddenly flattened onto the middle motor-node, because my opacity="" attribute gets translated into CSS opacity: 0.5 via the style attribute.

In order to solve the problem, then I have to render to a separate DOM tree that uses non-nested elements. For example, instead of having just motor-node elements in the DOM, the result will be something like this:

<motor-node position="..." rotation="...">
    this is rendered content

    <motor-node position="..." rotation="..." opacity="0.5">
        this is rendered content

        <motor-node position="..." rotation="...">
            this is rendered content
        </motor-node>
    </motor-node>
</motor-node>


```html
<!-- All motor-scene/node elements are inert now, and styled with display:none; -->
<motor-scene>
    <motor-node position="..." rotation="...">
        this is rendered content

        <motor-node position="..." rotation="..." opacity="0.5">
            this is rendered content

            <motor-node position="..." rotation="...">
                this is rendered content
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

<!-- We render to a separate tree using the non-nested approach -->
<div class="motor-scene" style="...">
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */)">
      this is rendered content
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.5">
      this is rendered content
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.5">
      this is rendered content
    </div>
</div>

Now, if opacity worked, we'd be able to also apply opacity to the inner-most motor-node, which would be automatically multiplied by the HTML/CSS engine:

<motor-scene>
    <motor-node position="..." rotation="...">
        this is rendered content

        <motor-node position="..." rotation="..." opacity="0.5">
            this is rendered content

            <motor-node position="..." rotation="..." opacity="0.5">
                this is rendered content
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

But, now that flattening is in place, we have to render the following instead (note the opacity of 0.25 which the library had to calculate manually):

<!-- All motor-scene/node elements are inert now, and styled with display:none; -->
<motor-scene>
    <motor-node position="..." rotation="...">
        this is rendered content

        <motor-node position="..." rotation="..." opacity="0.5">
            this is rendered content

            <motor-node position="..." rotation="..." opacity="0.5">
                this is rendered content
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

<!-- We render to a separate tree using the non-nested approach -->
<div class="motor-scene" style="...">
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */)">
      this is rendered content
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.5">
      this is rendered content
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.25">
      this is rendered content
    </div>
</div>

I hope you can see the problem now.

[trusktr]

So, about the user content, it would just work before, and opacity would be multiplied down the tree and the rendered content text would be transparent. But since we don't want opacity to flatten everything, things are tricky as far as managing the user's content. Let me explain.

First, the end library user writes the following markup which is not visible (display:none is set by the library). Note that the motor-node elements contain <h1> elements to be rendered:

<motor-scene>
    <motor-node position="..." rotation="...">
        <h1>this is rendered content</h1>

        <motor-node position="..." rotation="..." opacity="0.5">
            <h1>this is rendered content</h1>

            <motor-node position="..." rotation="..." opacity="0.5">
                <h1>this is rendered content</h1>
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

Then the library outputs the following DOM which will be part of what the user will actually see:

<div class="motor-scene" style="...">
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */)">
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.5">
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.25">
    </div>
</div>

Then the library needs to either (1) move the user's content over, or (2) clone the content over.

If we go with option (1), then the final result will be:

<motor-scene>
    <motor-node position="..." rotation="...">
        <h1>this is rendered content</h1>

        <motor-node position="..." rotation="..." opacity="0.5">
            <h1>this is rendered content</h1>

            <motor-node position="..." rotation="..." opacity="0.5">
                <h1>this is rendered content</h1>
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

<div class="motor-scene" style="...">
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */)">
        <h1>this is rendered content</h1>
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.5">
        <h1>this is rendered content</h1>
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.25">
        <h1>this is rendered content</h1>
    </div>
</div>

If we go with option (2), then the final result will be

<motor-scene>
    <motor-node position="..." rotation="...">
        <motor-node position="..." rotation="..." opacity="0.5">
            <motor-node position="..." rotation="..." opacity="0.5">
            </motor-node>
        </motor-node>
    </motor-node>
</motor-scene>

<div class="motor-scene" style="...">
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */)">
        <h1>this is rendered content</h1>
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.5">
        <h1>this is rendered content</h1>
    </div>
    <div class="motor-node" style="transform: matrix3d(/* Value calculated from multiplying the motor-node tree's values. */); opacity: 0.25">
        <h1>this is rendered content</h1>
    </div>
</div>

In either case, you can see that it will become tricky for the user to target/select the elements they wish to style or to work with.

[trusktr]

@dmvaldman Do you see what I mean?

[dmvaldman]

I'm sorry, I don't see what you mean. Generally speaking, I see the problem: opacity on a group causes the group's transforms to flatten. But I also see a simple solution: when you walk your motor-scene tree, store the opacity and apply them to its children recursively.

It seems option (1) has the output I would expect. I'm not sure what you mean by "moving the user's content over". It seems nothing has changed about the user's content.