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

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

From: Simon Fraser <simon.fraser@apple.com>
Date: Wed, 14 Sep 2016 15:58:29 -0700
Message-id: <07692AD6-4DF4-43A1-96B5-43E305D10D45@apple.com>
Cc: public-fx@w3.org
To: /#!/JoePea <trusktr@gmail.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 <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 <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.


Received on Wednesday, 14 September 2016 22:59:03 UTC

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