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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 28 Sep 2016 20:24:51 -0700
Message-ID: <CAGN7qDCEykNQJVsLzBKP2vcbnmZAiBVYVd5q4EVzsOdmOVPQgw@mail.gmail.com>
To: Nexii Malthus <nexiim@gmail.com>
Cc: "/#!/JoePea" <trusktr@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>, "www-style@w3.org" <www-style@w3.org>, Matt Woodrow <mwoodrow@mozilla.com>, Tien-Ren Chen <trchen@chromium.org>
On Wed, Sep 28, 2016 at 7:29 AM, Nexii Malthus <nexiim@gmail.com> wrote:

> I agree with this approach by JoePea.
>
> If anything, preserve-3d ought to be as its' namesake, preserving 3d being
> more important than trying to preserve opacity.
>
> I'm OK with opacity applying to its' own plane and popped planes escaping
> that grouping, it makes sense as a web developer, rather than 3d not being
> preserved on elements with preserve-3d (which would be surprising).
>

So, this would only be for opacity and not for any other effects?
This new behavior will make specs inconsistent and confusing for authors.
It will also be difficult to implement as this special-casing needs to
happen all over the browser's codebase which will lead to bugs.
Let's not add workarounds, especially if re-arranging elements will give
you the exact same effect.


> On Tue, 27 Sep 2016 at 20:26 /#!/JoePea <trusktr@gmail.com> wrote:
>
>> 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
>> space.
>>
>> 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 this:
>>
>> ```css
>> 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/
>>
>>
>> */#!/*JoePea
>>
>
Received on Thursday, 29 September 2016 03:25:26 UTC

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