[css-transforms-2] Is it necessary to serialize all 3 components of translate given the 3rd component is 0px

[BorisChiou]

Just a follow-up question of this issue. The new update of serialization of translate [1]:

• If a 2d translation is specified, the property must serialize with only one or two values (per usual, if the second value is 0px, the default, it must be omitted when serializing).
• If a 3d translation is specified, all three values must be serialized.

This question is only for the case: translate: 100px 100px 0px vs translate: 100px 100px. IIRC, it seems Gecko and Blink treat the translate(x, y) as translate(x, y, 0) while converting it into a matrix for computation. (Maybe it will simplify it if it only has 2d components.) Basically, 3d transformation is different from 2d transformation (by using different number of axes), so my question here is, what is the potential side-effects if we serialize translate: 100px 100px 0px as translate: 100px 100px? If the side-effects is not obvious in this case, could we make it simpler?

[1] https://drafts.csswg.org/css-transforms-2/#individual-transform-serialization

[BorisChiou]

cc @emilio

[emilio]

cc @tabatkins

TL;DR is: why is it incorrect to serialize translate: 10px 0 0; as translate: 10px. I don't get which side effect the spec talks about, at least for translation and scaling I'm pretty sure there's no such side effect.

[tabatkins]

translateZ(0) absolutely has side effects; it's a classic hack to trigger forcing the element onto its own rendering layer. Iirc all the 3d transforms do so, even if they're "identity" transforms otherwise.

[birtles]

As mentioned in w3c/fxtf-drafts#313, that's WebKit/Blink-specific behavior. It's not clear to me that it's necessary to preserve that behavior with the individual transform properties.

[tabatkins]

I was under the apparently-mistaken impression that the effect was present in all browsers!

That said, it would still be quite bad if, in WK/Blink, the element flipped from 3d to 2d in the middle of an animation, triggering all the weirdness of being demoted and then promoted again. So long as this quirk exists, I lean towards making sure the underlying value is consistent with keeping such animations 3d the whole time.

[birtles]

I guess I'm wondering if we can make Blink not interpret translate: 10px 10px 0 as a 3D transform? (While leaving transform: translateZ(0) as doing so.) I believe the individual transform properties are not shipping yet and are not implemented in WebKit so we can avoid propagating the quirk there?

Animating from translate: 10px 10px -10px to translate: 10px 10px 10px shouldn't trigger layer destruction/re-creation since so long as the element is animated, it effectively has will-change: translate applied and hence should keep its layer throughout.

[tabatkins]

I'm not sure why we'd want to interpret 10px 10px 0 as a 2d transform. It's clearly 3d; the author supplied three values.

While you're right that a CSS animation will indeed preserve the layer, setting things manually (either in an animation, or statically in a group of things with different z values) will still cause it to change its rendering if a 0 z value is treated as 2d.

[emilio]

Why would it? I don't get it. The fact that the z axis is zero doesn't change anything, regardless of whehter the user provided it or not.

[tabatkins]

As I stated above, yes it does, at least in current Chrome/WebKit. 3d transforms render differently than equivalent 2d transforms.

[emilio]

That seems like a bug in Chrome / WebKit to me.

[emilio]

And with that I mean: That's not something that deserves a spec to be changed.

[tabatkins]

Bug or not (it at least partially is), it's been part of WK/Chrome's transform implementation since it first shipped, and the web depends on that behavior as a "promote to a layer" perf hack. (It also has implications on text anti-aliasing, iirc.) We don't simplify translate3d() into a translate() if it has a 0 z argument, or vice versa.

The distinction is even maintained in TypedOM, which distinguishes between an unpassed z argument to CSSTranslate and a passed 0 value, and similar for the other 2d-and-3d constructors: https://drafts.css-houdini.org/css-typed-om/#dom-csstranslate-csstranslate

So far, I've carefully kept the various transform things consistent in this quirk, and I'd like to maintain that. I don't think we should drop it from some syntax forms and not others, because that makes it confusing to predict which behavior you're going to get in WK/Chrome browsers.

If we want to remove it, I'd like to remove it from all transform syntaxes.

[emilio]

You never simplify any transform function into another, unless you're interpolating, sure, but I don't think it compares apples-to-apples. I still think this is a bug. Browsers are much better at layerizing nowadays, and websites can use will-change: transform if they need to hint the browser. So I think there's no reason to do this.

[tabatkins]

@chrishtr What do you think about this? Any chance of us being able to stop doing the "transform: translateZ(0); causes rendering differences" behavior, since it's theoretically a no-op transform?

[chrishtr]

@chrishtr What do you think about this? Any chance of us being able to stop doing the "transform: translateZ(0); causes rendering differences" behavior, since it's theoretically a no-op transform?

I would like to make this change. The only reason we didn't already do it is out of concern for performance compatibility, and we already shipped the change for some low-memory devices.

I'll follow up with @progers to see if we can include this in current work.

[ewilligers]

Any chance of us being able to stop doing the "transform: translateZ(0); causes rendering differences" behavior, since it's theoretically a no-op transform?

This issue is about the translate, rotate, scale properties, not the transform property's functions. The suggestion is not that Blink change the transform property "non-binding hint" behavior; simply that translate etc. need not carry that behavior forwards as there is no web-compat need; authors can use will-change (or a paused animation) as a standards-based approach.

That said, it would still be quite bad if, in WK/Blink, the element flipped from 3d to 2d in the middle of an animation, triggering all the weirdness of being demoted and then promoted again

That doesn't happen, at least in Blink. We detect that the property is animating.

More Blink implementation detail:

If an individual transform property has a non-zero 3D component (or transform has a 3D function), Blink records a compositing reason: having a current 3D transform.

If an individual transform property (or transform) is animating, Blink records a compositing reason: having a current transform animation.

If an individual transform property (or transform) is mentioned in will-change, Blink records a compositing reason: having a will-change transform hint.

Any of these compositing reasons, and others, are sufficient to cause 3D behavior.

There are exploratory Blink CLs to record in the computed style if the individual transform has a supplied 3D component. These complicate animation implementation for no benefit other than
carrying forward to individual transform properties the translateZ(0) hint that predates will-change.

[chrishtr]

This issue is about the translate, rotate, scale properties, not the transform property's functions. The suggestion is not that Blink change the transform property "non-binding hint" behavior; simply that translate etc. need not carry that behavior forwards as there is no web-compat need; authors can use will-change (or a paused animation) as a standards-based approach.

That's true, but it seems to me it would be simpler to implement and more consistent for developers to just get rid of the current translateZ(0) hints. I think we will probably be able to do so now that GPU raster is pervasive, and there is an easy fix for a site which regresses performance.

[ewilligers]

All 4 browser engines serialize the gCS result for transform: scale3d(3, 2, 1) as matrix(3, 0, 0, 2, 0, 0), i.e. they don't report a matrix3d result.

[tabatkins]

This issue is about the translate, rotate, scale properties, not the transform property's functions. The suggestion is not that Blink change the transform property "non-binding hint" behavior; simply that translate etc. need not carry that behavior forwards as there is no web-compat need; authors can use will-change (or a paused animation) as a standards-based approach.

Right, I understand. But I don't like behavior being inconsistent when consistency isn't too bad, even if it's with a legacy bug.

That said...

I would like to make this change. The only reason we didn't already do it is out of concern for performance compatibility, and we already shipped the change for some low-memory devices.

and

All 4 browser engines serialize the gCS result for transform: scale3d(3, 2, 1) as matrix(3, 0, 0, 2, 0, 0), i.e. they don't report a matrix3d result.

both argue that the quirk should be removeable, which is great! If that's the case, happy to change all the supporting specs to match, and only consider something 3d if it's actually outside the screen's plane.

[AmeliaBR]

That doesn't happen, at least in Blink. We detect that the property is animating.

I assume your detection doesn't cover JS animations. So all JS animations would need to use will-change. But will-change doesn't really have defined behavior when it comes to which optimizations it uses for transformations. There's no way to say "will change to 3D" as opposed to "will change in scale" or "will change in position".

Even for CSS animations, it goes against general CSS behavior if pausing/freezing an animation at a translate Z of 0px has a different rendering compared to setting that transformation directly.

Worth mentioning as well, that for SVG there are some spec'd differences in behavior/validity for 2D vs 3D transformations (although implementations aren't all on board, e.g. for z-index).

[tabatkins]

There's no way to say "will change to 3D" as opposed to "will change in scale" or "will change in position".

Right, so all such changes must be applied with will-change:transform. No problems there.

Even for CSS animations, it goes against general CSS behavior if pausing/freezing an animation at a translate Z of 0px has a different rendering compared to setting that transformation directly.

Yes, this is one of the issues I was concerned about. But it looks like Chrome is okay with changing this to not have behavior differences.

[ewilligers]

Even for CSS animations, it goes against general CSS behavior if pausing/freezing an animation at a translate Z of 0px has a different rendering compared to setting that transformation directly.

Yes, this is one of the issues I was concerned about. But it looks like Chrome is okay with changing this to not have behavior differences.

No change in Blink animation behavior was mentioned. Pausing/freezing a 2D CSS animation in Blink can still have a different rendering compared to setting that 2D transformation directly. Pausing a animation at transform: translate(10px, 20px) is equivalent to having will-change: transform.

I understood @chrishtr to only be discussing a Blink change to make non-animated transform: translate3d(10px, 20px, 0px) be equivalent to transform: translate(10px, 20px).

[css-meeting-bot]

The CSS Working Group just discussed Is it necessary to serialize all 3 components of translate given the 3rd component is 0px, and agreed to the following:

• RESOLVED: For the individual transform properties if they spec a value that can be expressed as 2d we treat as 2d and serialize accordingly
• RESOLVED: Require transform funcitons to be downgraded to 2d if possible

The full IRC log of that discussion

<dael> Topic: Is it necessary to serialize all 3 components of translate given the 3rd component is 0px
<dael> github: https://github.com//issues/3305
<astearns> s/ring/read this/
<dael> TabAtkins: Question was the individual transform for translate spec distinction between 2d and 3d. If you explicitly give 2d it always does 2d, 3d is always 3d even if z is 0. Question of if it violates shortest serialization. Originally thought no because 3d has a meaning, but after looking any differences left we treat as bugs
<dael> TabAtkins: We're fine serializing as 3d. Fine with doing what heycam suggests.
<dael> TabAtkins: Does have minor changes b/c some difference as you do 3d animation as you pass through 0 if you pause right there it looks a little different. Considered minor by those in thread
<dael> dbaron: No longer animation diff between 2 value and 3 value syntax?
<dael> TabAtkins: If you pause a 3d transform while it's animating and at a state where it's 2d transform it will serialize differently. We're fine with that for now and consider it a bug being fixed
<dael> dbaron: I thought another difference was animation behavior depending on if you spec 2 or 3 values. My memory is a bunc hof the is it 2d or 3d are related to interpolation
<dael> AmeliaBR: If before and after states one is 2d and one is 3d they won't match us as being consistently the same. If one of them uses 3 values and 3rd is 0 I don't know how it's interpolated
<dael> AmeliaBR: With this proposal the 3 value disappears at computed and interpolates as a 2d
<dael> TabAtkins: dbaron do you have an example for your concern?
<dael> dbaron: If you're trying to interpole between translate and matrix and if the translate is 2d or 3d might effect if interpolation goes into 3rd dimension. But interpolation rules have changed so I'm not sure current state
<dael> TabAtkins: THink I'm in the same board.
<dael> dbaron: Basically want to make sure when you said there aren't significant differences you ran it by someone who is up to date
<dael> TabAtkins: eric w and chris have been in support
<dael> dbaron: Okay
<dbaron> s/up to date/up to date on the interpolation rules/
<dael> astearns: Would it be emilio on gecko's side?
<dael> dbaron: Possibly birtles, but I'm not sure.
<dael> dbaron: Possibly [missed]
<dael> astearns: dbaron would you be okay resolving
<dael> dbaron: I'm okay
<dbaron> s/[missed]/hiro/
<dael> AmeliaBR: I want to mention that this complicates how transforms are spec for svg which does make distinction between 2d transforms being regular layout vs 3d transforms being an isolating, flattening effect.
<dael> AmeliaBR: We haven't had a lot of implementors following spec to distinguish for SVG so might not be breaking. We do need people to commit to following through and cleaning up those areas of the spec and how do they work if we don't have clear consistent way to define 2d transform and 3d transform
<dael> TabAtkins: Yeah. Other evidence, Eric points out all 4 engines serialize scale 3d with 1 z-index as a 2d matrix. In general engines are loose even when you explicitly say 3d. Remaining errors with z-axis translate we're fine treating as a bug
<dael> astearns: Proposal?
<dael> TabAtkins: Option 1: For individual transform properties should they make 2d vs 3d distinction vs number of properties. We propose go on the value of the z-index
<dael> TabAtkins: In general should transforms be more permissive about 3d functions without 3d requiring transform being eq. to 2d. Have a mixture of behaviors, Blink is in favor oh downgrade to 2d when possible model
<dael> TabAtkins: Individual transform is easier.
<smfr> s/z-index/z value/
<dael> astearns: Prop: When there is a 3d value the transform properties are only 3d if the value is not 0
<dael> TabAtkins: If the transform can be expressed as a 2d we serialize as a 2d
<dael> astearns: Just serialization then?
<dael> AmeliaBR: More then serialization. It means that the round tripping is if you serialize and re-parse it's 2d so we don't want it to behave differen wiether you set the 3rd parameter or leave as default
<dael> TabAtkins: A translate with 3 values but z is 0 should not trigger full compositing
<dael> astearns: Trying to figure out how to state option 1
<dael> TabAtkins: For the individual transform properties if they spec a value that can be expressed as 2d we treat as 2d and serialize accordingly
<dael> RESOLVED: For the individual transform properties if they spec a value that can be expressed as 2d we treat as 2d and serialize accordingly
<dael> astearns: Second?
<dael> TabAtkins: Apply the above to all transform functions in normal transform property and then figure out implications for serialization and interpolation
<dael> AmeliaBR: Have some sort of resolution conditional on people doing web compat tests and get feedback from more authors?
<dael> TabAtkins: I'd rather not resolve if we're waiting for that.
<dael> AmeliaBR: At this point without a clear text of all places it'll impact it's hard to get author feedback
<dael> AmeliaBR: I'm a little worried about web compat depending on fine details
<dael> TabAtkins: I suspect this will be hard to get author feedback because it's technical and tiny. Compat-wise sure. Blink is okay with eating the compat, but if others are uncomfortable we can wait
<dael> AmeliaBR: You're right feedback won't happen until it's pushed.
<dael> astearns: I expect that making this change to figure out compat problems requires a resolution? Or would Blink experiment?
<dael> TabAtkins: We'd like spec text, but in a proposal is okay. So we can point to that's what we're doing
<dael> fantasai: We can resolve and say checking web compat
<dael> AmeliaBR: Not sure anywhere it makes sense to talk about this as at risk. I guess it's not a CR change
<dael> AmeliaBR: Widely impl but not officially stable
<dael> TabAtkins: Yes
<dael> AmeliaBR: Make the change with the awareness we might get author screams and have to revert
<dael> astearns: Prop: Require transform funcitons to be downgraded to 2d if possible
<dael> astearns: And we'll see what web compat shakeout is. Objections?
<dael> smfr: Just for serialization?
<dael> TabAtkins: Not sure the distinction. What would be different between yes and no to that
<dael> smfr: I guess not interpolation b/c 2d and 3d matching
<dael> TabAtkins: preserves compositing if you're in an animation
<dael> AmeliaBR: 2d gets upgraded to 3d to match endpoint
<dael> smfr: webkit uses it as a trigger
<dael> TabAtkins: That's what we're willing to stop doing
<dael> astearns: Any concerns smfr ?
<dael> smfr: No, worth experimenting
<dael> astearns: Objections?
<dael> RESOLVED: Require transform funcitons to be downgraded to 2d if possible

[progers]

This has little dependency on the issue but it was mentioned several times in this discussion that chromium uses translate3d(0, 0, 0) and translateZ(0) as a compositing trigger. We are attempting to remove this in https://crbug.com/1012775.

[yisibl]

@progers

Is there any conclusion on this issue? It seems that using --disable-features = DoNotCompositeTrivial3D can no longer be disable.

This has little dependency on the issue but it was mentioned several times in this discussion that chromium uses translate3d(0, 0, 0) and translateZ(0) as a compositing trigger. We are attempting to remove this in https://crbug.com/1012775.

[progers]

@yisibl, we attempted to remove the behavior where chromium uses trivial 3d transforms (e.g., transform: translateZ(0)) as a compositing trigger but found the performance tradeoff to not be worth it (it led to a measurable increase in re-painting). Unfortunately, we had to return to using these as a compositing hint. If you are still having issues with chromium in this area, please file a bug at https://crbug.com and I will take a look.

[tabatkins]

In that case, Agenda+ to go back to tracking "author explicitly gave a 3d value, we should serialize it as such even if it's equivalent to a 2d value".

[css-meeting-bot]

The CSS Working Group just discussed [css-transforms-2] Is it necessary to serialize all 3 components of translate given the 3rd component is 0px, and agreed to the following:

• RESOLVED: No change

The full IRC log of that discussion

<dael> Topic: [css-transforms-2] Is it necessary to serialize all 3 components of translate given the 3rd component is 0px
<dael> github: https://github.com//issues/3305
<dael> Rossen_: TabAtkins you brought this back?
<chrishtr> (had to leave early, conflicting meeting in second half-hour)
<dael> TabAtkins: Yes. Originally spec for individual transform properties distinguished between author writing 2d and 3d transform
<dael> TabAtkins: FF and maybe others objected b/c having z component of 0 is same as 2d translate.
<dael> TabAtkins: I objected at time b/c Chrome and WK had quirk where we used 3d transform presense as a hint to move to compositing layer. We were going to try and remove it which is why we accepted FF proposal
<dael> TabAtkins: Turns out we can't remove. We see a lot of extra paints from things not moving to compositing layer. B/c this is unacceptable amount of lost performance we're keeping the hack for now and may need forever.
<dael> TabAtkins: Want to revert spec to keep track of if something was 2d or 3d so you can round trip.
<flackr> I think interpolations are also different between 2d and 3d
<dael> emilio: This quirk is transform specific. Don't get why you need more
<dael> TabAtkins: All 3d transforms do it right now
<dael> emilio: I think that translate could be changed. I don't think. people are doing translate (0,0,0)
<dael> TabAtkins: I doubt they are. But if this is being kept around I'd like to be consistent across platform if we keep 2d and 3d
<dael> emilio: But transform is different b/c people use transform set
<dael> TabAtkins: Impacts how we serialize. Matrix or Matrix 3d for example
<dael> emilio: Seems wrong
<dael> dbaron: Does 2d or 3d influence animation?
<dael> TabAtkins: Only with rest of the quirk we talked about
<dael> flackr: I think this effects complialtion when intrep between matrix
<flackr> s/complialtion/decomposition
<dael> AmeliaBR: Animating between 2 2d transformations then your animation is entirely 2d. 2d to 3d it gets upgraded so animation becomes 3d
<dael> flackr: If there were a case where 3d matrix becomes 2d at 0 it could cause different interp. But only when fallback to matrix interp
<TabAtkins> I was wrong - it doesn't affect whether we serialize as matrix() or matrix3d()
<dael> emilio: And doesn't apply to individual transform properties right
<dael> flackr: Right, I don't think have to fall back to individual transform prop
<dael> smfr: WK hasn't imple individual and it would be nice as a break to get away from the hack.
<dael> emilio: TabAtkins I tested and it's not what you were saying
<dael> TabAtkins: Yep, I jsut tested and found the same
<dael> TabAtkins: smfr I agree I would love if authors use will-change but it won't effect if we can remove translate-z hack. It means have to be inconcsistent in typedOM b/c right now they track 2d or 3d and they'll want to serialize transformed values.
<dael> TabAtkins: I'm not happiest with hack being limited to just 3d transform functions. I don't like inconsistent if you turn transform into individual transform. Doesn't feel right to me. Even if we don't like hack existing I don't like inconsistency in platform
<dael> emilio: Will be inconsistent one way or the other
<dael> TabAtkins: If something is promoted to compositing is inconssitent. But the more obvious to authors as to if it's in typedOM I'd like to be consistent
<dael> emilio: Still don't think you should get is3d transform
<dael> TabAtkins: We want to change if you set with 3 we serialize to 3
<dael> AmeliaBR: And that's is3d for typed OM, right?
<dael> TabAtkins: Not sure what you're asking about
<dael> AmeliaBR: Clarify what emilio thinks is inconsistent. I understand prop is we consistenly keep track of if it's 2d or 3d
<dael> emilio: Computed serializes 2d for translate-set:0
<dael> TabAtkins: Yeah we've already got inconsistency in there. That's annoying.
<dael> TabAtkins: I'm fine accepting it's jsut transform functions that preserve 3d. And not even computed value. This is terrible. Everything is terrible
<dael> emilio: Agree
<dael> TabAtkins: I'm fine no change.
<florian> s/translate-set:0/translateZ(0)/
<dael> Rossen_: Prop: Close no change
<dael> Rossen_: And then hopefully someone will make TabAtkins feel better
<dael> emilio: I can say I'm sad too
<dael> Rossen_: We all share the pain
<dael> florian: There's precedent for writing this is sad within spec
<dael> RESOLVED: No change

[dbaron]

I discovered (via git blame) that while tests were added for this resolution, it still hasn't been edited into the spec. (If I hadn't happened to run git blame, I would have left the conclusion in Chromium bug 1180311 and Chromium bug 1180387 that the tests were buggy.

[dbaron]

I've made the changes for the first resolution in the spec in #6147.

I still need to work out exactly what the second resolution ("RESOLVED: Require transform funcitons to be downgraded to 2d if possible") means in terms of spec changes. It's not completely clear to me if the resolution was about just serialization, or about both serialization and interpolation, although I think it was the latter, and I think it also seems a bit odd if it were only the former, because it would mean that interpolation varies based on something that you can't see in the serialization. I think the implication of the discussion is that there should probably also be a note about the possibility of reverting the change if it's not sufficiently compatible.

[dbaron]

I also need to figure out when "downgraded to 2d" happens. I'm thinking it makes sense for the specified value of the property to preserve the functions as they are, but the computed value to do any potential downgrading. So this change would apply to the model of what the computed value is (including both the "Computed value:" line and w3c/css-houdini-drafts#1052), and then how that value is used in interpolation.