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

> 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.

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 00:10:25 UTC