Did this work before? Yes, in Chrome 52.

What I meant to say is: Let's not arbitrarily break the web just to suddenly follow a possibly-incorrect spec. The behavior was correct (in Chrome 52) as far as expectations go.

Firefox behaves the same as Chrome 52 in this regard, which strengthens the notion of our expectations as far as preserve-3d and opacity used together go.

I just tested that Safari 9 behaves the same as Chrome 52, and the codepen example works as expected.

This is (likely and unnecessarily) breaking 3D scenes that use opacity all around the web.

Another reproduction:

- Without opacity (works): https://jsfiddle.net/4m5ubpmp/1
- With opacity (broken): https://jsfiddle.net/4m5ubpmp/2

Here is the narrow bisect result:
==================================
https://chromium.googlesource.com/chromium/src/+log/f28a9d144d6f6655b1775adef9e1239ae05c682b..dab7c8f09b323e70dbcd457963e84d35276e0cea

Good Build: 52.0.2743.60
Bad Build: 53.0.2785.89

trchen@, could you please look into this change (https://chromium.googlesource.com/chromium/src/+/696f27afa62eb426545c29cefe0b0b43feeafe94) ?

Thank you!

This was an intentional change. See this intent to ship:

https://groups.google.com/a/chromium.org/forum/#!search/blink-dev$20opacity$20flattening/blink-dev/eBIp90_il1o/9q3M0ww2BgAJ

Also on chromestatus.com:

https://www.chromestatus.com/features/5671480339726336

@Chrishtr, this is "WontFix" because Chrome developers are simply (blindly?) following spec.

The spec is flawed.

Here's a public site that currently works in Firefox and Safari 9, but not Chrome 53: https://mightydevs.com

Note how in Chrome 53, the letters suddenly move into their correct positions when opacity reaches 1.0.

The solution to the problem would be to not use nested DOM, and fall back to the CSS3D before preserve-3d wherein we place all elements at the same level, then calculate world transforms and final opacities ourselves. This has a couple problems:

- We have to multiply opacities manually instead of the HTML engine.
- We have to multiply transforms manually instead of the HTML engine in order to determine final world transforms.
- Transforms and opacities are no longer cached by the HTML engine.
- It leads to ugly HTML markup where nothing is nested. Nesting elements and using preserve-3d brings about cleaner markup that matches with the structure of a 3D scene.
- Nested DOM makes 3D programming easier because transform caching is done by the HTML engine, not by end developers.

Chris, wouldn't you like for developers to write 3D scenes in the web (as far as DOM goes, not talking about WebGL which is a whole 'nother thing)? Doesn't it make sense to apply opacity to an object and for it not to become flat like paper?

If it didn't make sense, then why was it done that way in all browsers? ...Because it makes sense not to flatten things!

Come on, just imagine a game engine which has a scene graph, and an opacity is applied to something in the scene. Does it make sense to flatten it?

No.

Therefore it doesn't make sense to follow the spec in this regard.

Hi, thanks for the feedback.

We are not blindly following the spec. We have thought carefully about several
potential impacts of the old and new behavior. There have been several recent discussions on www-style and public-fx about this issue. That is a good place to discuss it, rather than this bug.

 Issue 649267  has been merged into this issue.

 Issue 652049  has been merged into this issue.

I got an email from a fellow web developer:

----------------

Hi

I came across your several notes on Chrome's 53's changes that can
break blending of elements
(https://bugs.chromium.org/p/chromium/issues/detail?id=646993, status
"wontfix").


Did you ever work out a workaround?  It looks like google's not going to fix it.


I saw that some of the suggestions mention a workaround having to do
with separating things out, but it was not clear what that meant.

Here's a codepen that works beautifully in Safari, and wonky in Chrome
(it's just the the 3 axes of 3d space fading in and out):

https://codepen.io/anon/pen/bRgMKB

It looks like you are way more intimately familiar with this stuff,
and I was wondering if you were able to deal with it.

--------------------

Seems that the problem might be cause by these changes. 

I made one that works:

https://codepen.io/anon/pen/mwWdxj

In order to make the change, I had to un-nest the DOM structure (which in this case was not a complicated DOM structure, luckily).

However, it doesn't seem that opacity was applied to the .assembly elements, so I'm not sure what is causing the problem (which does seem like transform flattening).

Besides un-nesting, I had to go and apply the parent .assembly transform to all the children, which was also cumbersome (imagine a more complicated DOM structure and the modifications required to apply opacity).