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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 14 Sep 2016 20:01:16 -0700
Message-ID: <CAGN7qDBL2wte0_E2QYKV8RAEprTS-TxWvO-ftmcaJ9DOUSMTgA@mail.gmail.com>
To: Simon Fraser <simon.fraser@apple.com>
Cc: "/#!/JoePea" <trusktr@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
On Wed, Sep 14, 2016 at 5:24 PM, Simon Fraser <simon.fraser@apple.com>
wrote:

>
> On Sep 14, 2016, at 5:09 PM, /#!/JoePea <trusktr@gmail.com> wrote:
>
> > But are they doing correct group opacity?
>
> The behavior in Chrome 52, Firefox, and Safari 9 is correct, yes. The
> implementation and wording isn't as important as the results, and the
> result in Chrome 53 is not correct.
>
> Actually, Chrome 52 and Safari behavior aren't doing correct group
> opacity. Testcase at <http://smfr.org/css/transforms/opacity-preserve-
> 3d.html>. You should not see the darkening where the layers overlap.
>
> Chrome 53 fixes this, but as you say, this can break web content. It's
> possible that we'll have to revert this spec change due to web compat
> issues.
>

Chrome had a use counter for content that was going to be affected:
https://www.chromestatus.com/metrics/feature/popularity#OpacityWithPreserve3DQuirk
0.0058% of web pages is affected by this change.

I thought Safari also changed this behavior. Didn't webkit used to
distribute parent opacity to its children?


> Do you have public web content that is broken by this change?
>
>
> On Sep 14, 2016 5:08 PM, "/#!/JoePea" <trusktr@gmail.com> wrote:
>
>> Pardon that I don't know the spec terminology, I'm just iterating what
>> the proper behavior is (what we see in Chrome 52).
>>
>> For reference, try first demo I linked in the Chrome issue, and nite that
>> it is now broken in Chrome 53, but works fine in Firefox and Safari 9.
>>
>> We can't be breaking the web like this, and we can't be introducing
>> behaviors that don't make sense from a 3D stand point.
>>
>> On Sep 14, 2016 5:04 PM, "/#!/JoePea" <trusktr@gmail.com> wrote:
>>
>>> I see what you're saying: you're just re-iterating the spec, whose
>>> design is flawed.
>>>
>>> The behavior should be just as it were before Chrome 53 was released.
>>> It's all works nicely in Chrome 52.
>>>
>>> How you will word that in the spec is a different issue, and all I'm
>>> saying is that Chrome 52 exhibits proper behavior, as do current Firefox
>>> and Safari.
>>>
>>> Chrome 53 follows this flawed spec, and is therefore broken.
>>>
>>> On Sep 14, 2016 4:58 PM, "Simon Fraser" <simon.fraser@apple.com> wrote:
>>>
>>>>
>>>> On Sep 14, 2016, at 4:24 PM, /#!/JoePea <trusktr@gmail.com> wrote:
>>>>
>>>> > Authors can work around this by applying opacity on their leaf
>>>> elements individually, or by using rgba() colors etc.
>>>>
>>>> That's not a valid workaround because in many cases there needs to be
>>>> opacity on parent elements.
>>>>
>>>> For example, imagine a game object which is a vehicle. The parent
>>>> contains sub children positioned relatively to the parent (using tranforms)
>>>> in order to place the doors, wheels, and body of the vehicle (maybe it is a
>>>> truck, car, or motorcycle). Now, imagine in this game that the cars are
>>>> alive (like in the movie "Cars", and one of them is a ghost. To achieve
>>>> this, we apply an opacity to the parent element, which makes the whole car
>>>> transparent. Or, imagine that there is a "ghost" car in a racing game in
>>>> order to show where you were during your last attempt, so that you can
>>>> attempt to beat your last time. We apply opacity to the whole car, and
>>>> expect for thecar to remain 3D, not be flattened.
>>>>
>>>> In cases like with the car examples, we cannot simply apply opacity to
>>>> leaf-most elements. Furthermore, rgba() colors apply only to things like
>>>> background, border, text colors, etc, but not to the whole element, so
>>>> that's not a workaround.
>>>>
>>>> The only workaround is to NOT use nested elements, but that prohibits
>>>> the use of CSS transform caching that we get with the nested approach. It
>>>> is imperative that the nested approach works along with opacity without
>>>> flattening, otherwise this change is detrimental to 3D in the web, and is
>>>> completely unintuitive. Making a 3D object flat because it has opacity
>>>> simply does not make sense (it doesn't matter if that's what spec says).
>>>>
>>>> For reference, the "nested" approach is the form of CSS3D that IE10/11
>>>> does not support, with preserve-3d.
>>>>
>>>> Grouping is fine, as it makes much sense for all children to inherit
>>>> the opacity level and have it multiplied with their own opacity (just like
>>>> how positional transformations work), but additional flattening is simply
>>>> not a good design choice.
>>>>
>>>>
>>>> Unfortunately you can't have one (grouping) without the other
>>>> (flattening), at least with the 3D implementation in WebKit, and I suspect
>>>> other UAs too. The way that preserve-3D works is to hoist descendant layers
>>>> up to effectively become siblings of their parent/ancestor elements in the
>>>> same 3D-rendering context, so they call get positioned and depth-sorted in
>>>> the same 3D coordinate space. There's no way you can do group opacity in
>>>> this model without rendering some subtree of transformed elements into a
>>>> texture (which is flattening).
>>>>
>>>> Simon
>>>>
>>>>
>>>> Please consider modifying the spec so that opacity does not destroy 3D
>>>> scenes. Also please consider the same for mix-blend-mode, and similar
>>>> effects.
>>>>
>>>> Best regards,
>>>> - Joe
>>>>
>>>> */#!/*JoePea
>>>>
>>>> On Wed, Sep 14, 2016 at 3:58 PM, Simon Fraser <simon.fraser@apple.com>
>>>> wrote:
>>>>
>>>>> On Sep 14, 2016, at 3:51 PM, /#!/JoePea <trusktr@gmail.com> wrote:
>>>>>
>>>>> The following is a big problem for people making 3D scenes, and I
>>>>> really think this needs to be rethought:
>>>>>
>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=646993
>>>>>
>>>>> Not only does it break existing apps, but it also makes it difficult
>>>>> to create 3D HTML scenes that involve opacity. The intuitively expected
>>>>> behavior (as listed in that issue) is that opacity applies to children but
>>>>> does not cause unintuitive flattening.
>>>>>
>>>>> If browsers follow the latest spec, then we are making it more
>>>>> difficult to do and discouraging 3D in the web, which I don't think is what
>>>>> we want.
>>>>>
>>>>> The faulty part of the spec is here: https://drafts.csswg.org
>>>>> /css-transforms/#grouping-property-values
>>>>>
>>>>> It states that opacity should cause grouping, which is what causes the
>>>>> flattening.
>>>>>
>>>>> Is there an alternative way to achieve opacity less than 1.0 without
>>>>> flattening of 3D scenes, that I may have missed? Unless there's an
>>>>> alternative, this behavior is a bad idea for authors of 3D HTML scenes.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
Received on Thursday, 15 September 2016 03:01:45 UTC

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