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

My two cents is that the web spec should be like laws --- codify what
people do and people expect in the real world. Therefore I personally
support the proposal "when an element have both
transform-style:preserve-3d and opacity other than 1, the opacity
value applies to the stacking context subtree in the current plane,
and also applies separately to each planes propagated from the
descendants."

However such proposal is ambiguous when other aspects of the spec is
ambiguous. For example, the current spec doesn't define what makes a
plane:

<style> div { transform-style:preserve-3d; } </style>
<div style="opacity:0.5;">
    A
    <div style="transform:translateZ(0);">B</div>
    <div style="position:relative; z-index:0;">C</div>
</div>

Should be the stacking order equivalent to:

<style> div { transform-style:preserve-3d; } </style>
<div style="opacity:0.5;">
    A
    <div style="position:relative; z-index:0;">B</div>
    <div style="position:relative; z-index:0;">C</div>
</div>

Because everything are co-planar, or:

<style> div { transform-style:preserve-3d; } </style>
<div style="opacity:0.5;">A</div>
<div style="opacity:0.5; transform:translateZ(0);">B</div>
<div style="opacity:0.5; position:relative; z-index:0">C</div>

Because every child stacking context is considered an individual plane, or:

<style> div { transform-style:preserve-3d; } </style>
<div style="opacity:0.5;">
    A
    <div style="position:relative; z-index:0">C</div>
</div>
<div style="opacity:0.5; transform:translateZ(0);">B</div>

Because C is considered on the same plane as A?

I actually had a lengthy debate with Chris before we shipped the
change, and I was convinced that the new spec will introduce least
ambiguity understood by vendors and web developers (which is a very
desirable property of a spec!). We are fully aware the spec change
won't be backward compatible. However the fact that you complained
about the spec change actually reinforced the confidence that we can
get away with it, because that implies this area is still actively
developed, the contents are alive, and the framework authors will
adapt to the change. In other words, we favored simplicity and
unambiguity over convenience on this decision.

On Mon, Sep 26, 2016 at 5:06 PM, /#!/JoePea <trusktr@gmail.com> wrote:
> If you guys are against opacity being applied to descendants of the targeted
> element, then maybe, instead of flattening, the opacity should just apply to
> the target element's own paint and those descendants that are popped out and
> exist in the same 3D space would not be affected by the opacity. Opacity
> multiplication would be up to the end developer, and I could live with that.
>
> But the current behavior is wrong from a 3D perspective. Opacity should not
> suddenly and unexpectedly move all the vertices of a 3D object onto a common
> plane.
>
> Please, let's revise the spec, no matter how hard that may be, and let's get
> it right.
>
> - Joe
>
> /#!/JoePea
>
> On Fri, Sep 23, 2016 at 12:58 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>>
>>
>>
>> On Fri, Sep 23, 2016 at 12:39 AM, Matt Woodrow <mwoodrow@mozilla.com>
>> wrote:
>>>
>>>
>>> On 22/09/16 11:37 PM, Rik Cabanier wrote:
>>>
>>>
>>> In addition, your proposal *also* affects web content because opacity is
>>> now applied to the group instead of being distributed to the children.
>>>
>>> It's true, but I figured it would be close enough to the old rendering
>>> that the majority of existing content would work with it (assuming they just
>>> want opacity, not specifically opacity distributed to the children) while
>>> also being correct wrt group-opacity and not implementation dependent.
>>>
>>>
>>>>
>>>> This thread was started by an author who's content was broken, so it
>>>> seems reasonable to re-visit these assumptions.
>>>
>>>
>>> Yes, we went over his examples and told him how to fix it (= apply
>>> opacity to the elements)
>>> Since Firefox knows that it's flattening, could it create a warning in
>>> the console and point to an MDN page with more information?
>>>
>>> 1:
>>> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eBIp90_il1o/jrxzMW_4BQAJ
>>> 2: https://bugzilla.mozilla.org/show_bug.cgi?id=1250718
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1278021
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1229317
>>>
>>>
>>> I still think that applying group-opacity to a subset of a 3d scene is a
>>> reasonable use case (that can't be easily solved without this), and one that
>>> we could support without breaking anything worse than we already plan to.
>>>
>>> Doesn't look like this is getting much traction though, so I'll probably
>>> just accept the spec change and go ahead with ship flattening of opacity in
>>> Firefox.
>>
>>
>> Good to hear! This was a great discussion.
>> If you (or anyone else) can come up with a better solution, maybe we can
>> add it to the spec as another value when we integrate Simon Fraser's
>> proposal.
>
>

Received on Tuesday, 27 September 2016 00:54:19 UTC