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

On Wed, Sep 21, 2016 at 5:38 AM, Matt Woodrow <mwoodrow@mozilla.com> wrote:

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

Thanks for making that available. (For people on MacOS, you have to launch
firefox from the command line. It wouldn't launch from the finder for me)

Your example shows your proposal nicely. I tried to create one where the
planes cross but firefox seems to render that incorrectly.
I have a counter-example here: http://codepen.io/adobe/pen/WGoKjA

If you have the following markup:

<div id="wrapper">
  <div id="addalpha">
    <div id="sq1">Square1</div>
    <div id="sq2">Square2</div>
  </div>
  <div id="sq3">Square3</div>
</div>


With your proposal, sq1 and sq 2 will be placed in the world, rendered to
texture and then have alpha applied.
However, sq3 is in between sq1 and sq2. How should this render?