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: Wed, 14 Sep 2016 16:24:51 -0700
Message-ID: <CAKU1PAVxN1djOo=RnRX6pPYdi2wJ5GhP9=EmiYKFU+6v3zy-rw@mail.gmail.com>
To: Simon Fraser <simon.fraser@apple.com>
Cc: public-fx@w3.org
> 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.

Please consider modifying the spec so that opacity does not destroy 3D
scenes. Also please consider the same for mix-blend-mode, and similar

Best regards,
- Joe


On Wed, Sep 14, 2016 at 3:58 PM, Simon Fraser <simon.fraser@apple.com>

> 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 Wednesday, 14 September 2016 23:25:59 UTC

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