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: Thu, 22 Sep 2016 13:32:24 +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: <f1f025b1-1f82-84b3-b47e-31d13e4a19b3@mozilla.com>


On 22/09/16 12:38 PM, Rik Cabanier wrote:
>
>
> I disagree :-) I think it's the worst choice since it renders visibly 
> incorrect.
>
> To demonstrate the issue, I've update the sample so it's more obvious: 
> https://codepen.io/adobe/pen/QKdjKb and I've also attached a 
> screenshot. You can hover over the left square to remove some opacity.
> With your patch, content in an opacity group introduces extra render 
> passes so things are drawn first in reverse DOM order and then on the 
> 3d plane.
> The codepen markup is as follows:
>
>     <div id="wrapper">
>       <div id="addalpha">
>         <div id="sq1">Square1</div>
>         <div id="sq2">Square2</div>
>       </div>
>       <div id="sq3">Square3</div>
>     </div>
>
> In the firefox nightly browser, sq3 is drawn first followed by the 
> opacity group of sq1 and sq2.
> If we put sq3 first in the dom, it will be drawn last.
>
> I wish there was an easier solution to this problem that's always 
> consistent. Does anyone know how this problem is fixed in 3d applications?
That's fine, but you also think it's sufficiently better on these cases 
(where there is no 'right' behaviour and we're just picking which one is 
the least-wrong) that it makes up for breaking uses cases like my 3d cube?

I personally think it's worth getting the defined use cases perfect, and 
accepting slightly worse behaviour for the undefined cases like yours, 
but we might have to agree to disagree here.

- Matt
Received on Thursday, 22 September 2016 01:33:07 UTC

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