W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2016

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

From: /#!/JoePea <trusktr@gmail.com>
Date: Mon, 26 Sep 2016 17:06:01 -0700
Message-ID: <CAKU1PAX1k22eQU5ok=-DrftEXbqm2Y3KGyLj7bKKFLmVT0_7Hw@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Matt Woodrow <mwoodrow@mozilla.com>, Tien-Ren Chen <trchen@chromium.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Chris Harrelson <chrishtr@google.com>, Simon Fraser <simon.fraser@apple.com>, "public-fx@w3.org" <public-fx@w3.org>, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Nexii Malthus <nexiim@gmail.com>
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
>> <https://groups.google.com/a/chromium.org/forum/#%21msg/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:07:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:57 UTC