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

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

From: Matt Woodrow <mwoodrow@mozilla.com>
Date: Wed, 21 Sep 2016 16:38:31 +1200
To: Rik Cabanier <cabanier@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, /#!/JoePea <trusktr@gmail.com>, Chris Harrelson <chrishtr@google.com>, Simon Fraser <simon.fraser@apple.com>, "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <7ae78f68-f4db-c5e6-83ca-22bea2bab22a@mozilla.com>


On 21/09/16 12:57 PM, Rik Cabanier wrote:
> What makes opacity so special? (Or are you proposing that other 
> effects also inherit this behavior?)
> "naturally" is also ambivalent. I find the current Chrome behavior 
> more natural.
>
>     Opacity is special because it doesn't really matter if you apply
>     it before or after the transform. Filter might also fall into this
>     category, but most of the others (mix-blend, clipping) seem like
>     their position in the preserve-3d really matter.
>
>
> I don't see why that is. clipping and blending can be done pre/post 
> transform.

I guess that's true as well. We have existing web content relying on us 
not flattening opacity, so I think it makes sense to start with opacity. 
The others might make sense too, or we might have webcompat issues 
changing those.

>
>     I guess natural is a poor choice of words. I was thinking of the
>     use case where you take a set of elements to form an 'object' (say
>     a 3d cube), apply opacity to that (true, group opacity) and then
>     position it within the outer scene (say a whole set of cubes that
>     rotate in a carousel). As far as I can tell, there's no way to
>     achieve this effect with the current spec and my suggestion makes
>     it possible.
>
>
> Yes, that is a current issue in the spec. Once you're in a 3d context, 
> you can't introduce group opacity and not expect it to flatten.
> Simon Fraser made a proposal 2 years ago to fix this: 
> https://logs.csswg.org/irc.w3.org/css/2014-01-28/#e237881/https://lists.w3.org/Archives/Public/www-style/2014Feb/0053.html
>
> His proposal was to redefine the values of transform-style so it's not 
> ambiguous. Unfortunately, since the prefix was dropped, we likely have 
> to introduce a new name if we go down that path :-\
This is the core of my point, why should you have to expect it to 
flatten? I've shown that this isn't actually a requirement, only the 
convenient way of handling group opacity

Given that we have existing content that depends on *not* flattening, 
then I feel that we've missed the chance to do the convenient thing and 
we have to handle opacity without flattening.

I made a simple testcase that shows what I mean, and then hacked up a 
prototype of my suggestion in Firefox to show rendering it as I suggest:

http://people.mozilla.org/~mwoodrow/cube.html

Rendering examples:
Chrome: http://people.mozilla.org/~mwoodrow/chrome-cube.png
Safari: http://people.mozilla.org/~mwoodrow/safari-cube.png
Firefox-with-prototype: 
http://people.mozilla.org/~mwoodrow/firefox-prototype-cube.png

You can try out my prototype builds if you'd like, though there's 
probably bugs for harder cases:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c1df8944930e
https://archive.mozilla.org/pub/firefox/try-builds/mwoodrow@mozilla.com-c1df8944930e39bea120afd5e86ba45ffc4b1c3d/

  - Matt
Received on Wednesday, 21 September 2016 04:39:07 UTC

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