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

On Thu, Sep 15, 2016 at 10:02 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> On Wed, Sep 14, 2016 at 8:44 PM, /#!/JoePea <trusktr@gmail.com> wrote:
>> 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.
>
>
> I don't understand how you come to that conclusion.
> The new behavior seems more logical since it applies the opacity to element
> that has the property applied. The old implementation distributed the value
> to its children which is counter to any other CSS value.
> Are you proposing that we also do this for filters, blending, backdrop
> blurring and other effects, or is opacity special in some way,
>
> As Simon stated, if you want the old behavior, just add a selector to your
> opacity parameter so it's applied to the children.

Yes. This is not a spec bug, it's a natural and unavoidable
consequence of doing a "group effect", which opacity, filters, and a
few other effects are.  These types of effects require the group to be
rendered as a unit, then have the effect applied; in 3d space, this
has the effect of flattening them. (If you didn't flatten, then other
items could get between the individual pieces in 3d order, and there's
no consistent or sensible way to render that. This is identical to how
z-index is "flattened" by opacity and other group effects, so you
can't sandwich elements elsewhere in the page between the elements in
the group.)

If you want to sandwich things, you need to push the effect further
down into the leaves, so it doesn't group as many things together.
This lets you do more re-ordering, but has a different visual effect -
if one item occludes another in a group, when they're made transparent
they still occlude; if they're made individually transparent, you'll
be able to see the second item behind the first.  Similar differences
exist for other group effects - if you're doing a gaussian blur,
blurring two boxes as a group can look quite different than blurring
them individually.

As Simon said, Chrome 52 and earlier Safari are simply buggy and not
"grouping" things correctly; they're instead automatically pushing the
opacity down further toward the leaves when 3d is involved.  If you
want the same effect, just do so manually, as Rik recommends.

(We had an almost identical request in the SVG Working Group a few
days ago. I posted
https://github.com/w3c/svgwg/issues/264#issuecomment-246750601 as an
extended explanation of what's happening.)

~TJ

Received on Thursday, 15 September 2016 18:17:16 UTC