W3C home > Mailing lists > Public > www-style@w3.org > September 2016

[css-transforms] Handling combined opacity and preserve-3d

From: /#!/JoePea <trusktr@gmail.com>
Date: Tue, 27 Sep 2016 19:26:26 +0000
Message-ID: <CAKU1PAXZCopvkNk6_weYVqQC1HLkY-NR1rA-R6-WLPqRHVcLkQ@mail.gmail.com>
To: public-fx@w3.org, www-style@w3.org, www-style@w3.org, Matt Woodrow <mwoodrow@mozilla.com>, Tien-Ren Chen <trchen@chromium.org>
> What is the expected behaviour when transform-style:preserve-3d and
> opacity are combined on a single element?

> The current working draft [1] makes no mention of what to do.

> I wrote a test to check the behaviours of various browsers [2] and it
> looks like both Blink and Webkit apply the opacity to each of the
> preserve-3d 'leaves' instead of applying it as a group.

> Gecko flattens that subtree to apply the opacity as a group, and in
> currently Nightly we make a better attempt to sort what remains.

> The current editors draft [3] also requires flattening, but I don't
> think that's going to be web compatible, as we've already found websites
> that are using this [4].

> I think it's worth updating the working draft to spec the Blink/Webkit
> behaviour, since the editors draft is a big change and unlikely to be
> finished quickly. I'll happily fix Gecko to match this behaviour.

Let's fix the spec, please! It is obvious that new 3D scenes are not the
same as 2D scenes rendered according to specs that are decades old. Opacity
does not need to be absolutely grouping when in a 3D context, it only needs
to group the content which remains on the 2D plane of the element with the
opacity property, and not the 3D children that are popped out into 3D

In Tien's email here
<https://lists.w3.org/Archives/Public/public-fx/2016JulSep/0071.html>, he
asks if a plane with translateZ(0) should be popped into it's own new
plane. I believe yes.

And then, once that's solved, opacity (and other backdrop-interacting
properties) can apply only to the plane that they are applied to, almost as
if they are still grouping, but that 3D popped-out content on new planes
escape the grouping and are not affected.

Additionally, I've proposed that the end-developer should have control over

div {
  blend-3d: auto; /* Defaults to "single" which does not multiply down 3D
descendant elements in a 3D context. */

div {
  blend-3d: single; /* does not multiply down 3D descendant elements in a
3D context. */

div {
  blend-3d: multiply; /* multiplies down 3D descendant elements in a 3D
context, and perhaps it stops at the next 3D descendant element that has
"blend-3d: single". */

This would let developers choose what behavior they want, and does not
break CSS principles like the new behavior does (because the new behavior
requires markup changes or DOM restructuring in order to achieve the
desired visual style).

At the very least, if you guys decide that such a property like `blend-3d`
is not to be introduced, then just apply opacity onto the plane that
opacity is applied to, and let 3D content escape the grouping. This would
still be great because it does not break CSS principles, and the
end-developer can still manually multiply and apply opacities to descendant
3D elements.

> Thanks!
> - Matt
> [1] http://www.w3.org/TR/css-transforms-1/#transform-style-property
> [2] http://people.mozilla.org/~mwoodrow/preserve3d-opacity.html
> [3] https://drafts.csswg.org/css-transforms/#grouping-property-values
> [4] http://lacigrona.com/carta/comida/

Received on Wednesday, 28 September 2016 12:26:53 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:00 UTC