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

On Wed, Sep 14, 2016 at 8:01 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> Chrome had a use counter for content that was going to be affected:
> https://www.chromestatus.com/metrics/feature/popularity#OpacityWithPreserve3DQuirk
> 0.0058% of web pages is affected by this change.
>
> I thought Safari also changed this behavior. Didn't webkit used to
> distribute parent opacity to its children?

As far as I checked today, Safari 9.1.2 (11601.7.7) still follows the
legacy behavior.

>>> On Sep 14, 2016 5:04 PM, "/#!/JoePea" <trusktr@gmail.com> wrote:
>>>>
>>>> I see what you're saying: you're just re-iterating the spec, whose
>>>> design is flawed.
>>>>
>>>> The behavior should be just as it were before Chrome 53 was released.
>>>> It's all works nicely in Chrome 52.
>>>>
>>>> How you will word that in the spec is a different issue, and all I'm
>>>> saying is that Chrome 52 exhibits proper behavior, as do current Firefox and
>>>> Safari.
>>>>
>>>> Chrome 53 follows this flawed spec, and is therefore broken.

Personally I'm neutral about this issue. I think either behavior makes
sense, and I'm happy to implement either if a consensus has been made.

I agree with you that distributing opacity to planes may be a
desirable feature. Also we should try our best to write spec that
matches existing behavior. However I don't agree with you that the
spec'd behavior is flawed. In fact the spec'd behavior is clean,
well-defined, does not lose expressiveness, and is how I would have
designed it if there is no legacy contents to support.

There wasn't a written spec for the existing behavior in the first
place. Basically every vendors tried to mimic WebKit behavior, then
introduced tons of inconsistencies in corner cases. I think the best
way to spec the current behavior is that "opacity applies to the
current stacking context, and also applies to each descendant planes
in the current 3D context individually". However we don't have a
definition for "3D planes", and each vendors just implement behavior
that's most convenient for them.

For example, in WebKit/Blink, we basically treat every "composited
layer" a 3D plane, where compositing is an internal concept which
should have never leaked to the API. http://jsbin.com/kiluwo/
demonstrates why this is bad. The green box gets popped into a 3D
plane depending on whether a "difficult" child presents.

Also in Firefox, the decision whether to pop a stacking context to its
own plane is different from what other vendors do. The other vendors
treat transform:translateZ(0) and transform:translateX(0);
differently, where the former was considered a 3D transform (thus
popping the current stacking context to a new plane) because it
included a 3D primitive, while Firefox considered both transforms 2D
(because the final matrix has only 2D components).

I did an extensive research in this issues and made a list of
consistencies: https://docs.google.com/spreadsheets/d/1XaQL_SJj7VRV1oIYX5HRK1TMDS40YRP6owBZxYX-NTY/edit#gid=1213074250
I really wish the spec authors could study my list and come up with a consensus.

What I'm trying to say is that the old behavior is not as good as you
thought. It is in fact very ambiguous and quirky. I'm not saying that
it can't be spec'd in a well-defined way, but it is not trivial and
needs spec authors & vendors to put efforts into it.

Received on Thursday, 15 September 2016 04:02:03 UTC