[css-transforms-2] Serialization of individual transform when the animation is at 0% or 100%

[BorisChiou]

About the serialization of the interpolation result (for individual transforms), our wpt has a testcase like this:

test_interpolation({
  property: 'scale',
  from: 'none',
  to: '4 3 2',
}, [
  {at: -1, expect: '-2 -1 0'},
  {at: 0, expect: 'none'},
  {at: 0.125, expect: '1.375 1.25 1.125'},
  {at: 0.875, expect: '3.625 2.75 1.875'},
  {at: 1, expect: '4 3 2'},
  {at: 2, expect: '7 5 3'}
]);

We do animation from none to 4 3 2 in the above testcase. However, the spec [2] says

When translate, rotate or scale are animating or transitioning, and the from value or to value (but not both) is none, the value none is replaced by the equivalent identity value (0px for translate, 0deg for rotate, 1 for scale).

This means at 0%, the serialization should be 1 1 1 because we should convert it into scale3d, right? It seems the wpt converts it back to none for serialization at 0% or 100% for now.

Besides, the following question is:
if we do interpolation from 26 17 9 to 2 1, the serialization result at 100% is 2 1 or 2 1 1? Just want to know should we treat the serialization at 0% and 100% as a special case for individual transform? It seems the spec says we should convert it to a interpolatable value during animation, but the current wpt doesn't follow this? (Or maybe other specs define this but I didn't notice.)
Thanks.

cc @birtles

[1] https://github.com/web-platform-tests/wpt/blob/master/css/css-transforms/animation/scale-interpolation.html
[2] https://drafts.csswg.org/css-transforms-2/#individual-transforms

[birtles]

This relates to the issue of when it's acceptable for a UA to recognize that no interpolation is necessary and use one of the endpoints as-is (e.g. if there is a step timing function and you are on the first/last step etc.).

I believe this came up in the context of the cross-fade() function. I believe in that situation I was encouraging us to define output of cross-fade() so that it always produces the most simplified form. That way a UA can use an endpoint as-is without it being observable.

I wrote a test case demonstrating where browsers differ on this but now I can't find the issue where that came up so it might not have been cross-fade() after all.

Regarding the serialization in this issue, I think it relates in part to whether or not we can get Blink to stop treating translate: x y 1 as a 3D transform (and hence triggering layerization) or not. If we can do that, it might make sense to define translate: 1 1 1 as serializing as none, I'm not sure.

[stephenmcgruer]

Came across this whilst porting more interpolation tests from Blink internal to WPT. A similar problem exists for how many axes should be included, e.g. the following failures from Firefox:

FAIL CSS Transitions: property <scale> from [26 17 9] to [2 1] at (1) should be [2 1] assert_equals: expected "2 1 " but got "2 1 1 "
FAIL CSS Transitions: property <scale> from [1] to [10 -5 0] at (0) should be [1] assert_equals: expected "1 " but got "1 1 1 "

Blink is short-circuiting the interpolation at 0%/100%, so we don't expand (say) 2 1 to 2 1 1, and thus output just two number (which is a valid serialization). Would be nice to specify what happens both here and in the original 'none' case (maybe just by spec-ing in web-animations that interpolation can't be short-circuited, though that would nix some of our optimizations - not sure how important they are atm).

[BorisChiou]

This should be a general issue I think. IMO, when running an animation, getCompustedStyle() should return the current interpolated value, even at 0% and 100%. This issue may happen frequently on individual transform because none is converted into an equivalent interpolable value and we may promote 2d transform to 3d transform if needed, so the interpolable value could be different from the keyframe value.
More examples, on Gecko:

from { rotate: none; }
to { rotate: 4 5 6 45deg; }

While calling getComputedStyle() at 0%, the returning interpolated value is something like (4 5 6 0deg) * 1.0 + (4 5 6 45deg) * 0.0, so the result is 4 5 6 0deg

from { rotate: 45deg; }
to { rotate: 1 -1 0 60deg; }

While calling getCompustedStyle() at 100%, the returning interpolated value is something like (0 0 1 45deg) * 0.0 + (1 -1 0 60deg) * 1.0 and then do normalization on the axis part, so the result is 0.707 -0.707 0 60deg.
While calling getCompustedStyle() at 0%, the returning interpolated value is something like (0 0 1 45deg) * 1.0 + (1 -1 0 60deg) * 0.0 and then do normalization on the axis part, so the result is 0 0 1 45deg, which is serizlized as z 45deg.

Blink is short-circuiting the interpolation at 0%/100%, so we don't expand (say) 2 1 to 2 1 1, and thus output just two number (which is a valid serialization)

But basd on the serialization part, if it is a 3d trasnform, we should serialize it as a 3d, right?

[stephenmcgruer]

Sorry, I meant to update this last week with the results of my investigations, but I forgot :(. I was originally ready to say "yes, the spec clearly says you always interpolate, Blink is just buggy", but then I found #4378 and the world got a bit weird again. I held off on updating this issue because I wanted to get that one resolved (if there even is a resolution to be done), but then I didn't do any work to resolve it :(.

But basd on the serialization part, if it is a 3d trasnform, we should serialize it as a 3d, right?

Maybe I misunderstand, but to Blink this isn't a 3d scale (being pedantic, in this case it wasn't a transform ;)) at this point exactly because we've short-circuited the interpolation. And as per https://drafts.csswg.org/css-transforms-2/#individual-transform-serialization, 2d scales are just 1-2 numbers.

[BorisChiou]

I see. So the problem is: should we short-circuited the interpolation. Gecko doens't, so it always return the interpolated value (which is 3d scale). However, Blink return the original from/to value (which is 2d scale). Anyway, need the feedback from CSSWG.

[css-meeting-bot]

The CSS Working Group just discussed Serialization of individual transform when the animation is at 0% or 100%, and agreed to the following:

• RESOLVED: We return the values the animation is working on while the animation is going and that includes the endpoints per the definition in web animations

The full IRC log of that discussion

<dael> Topic: Serialization of individual transform when the animation is at 0% or 100%
<dael> github: https://github.com//issues/3290
<dael> astearns: Also from heycam.
<dael> AmeliaBR: Overview. When interpolating transform functions you often first need to do processing to upgrade function into a form that interpolates with other end. At exact moment when at beginning or end of animations or in frozen animation state is serialization using the upgraded functions or is it using the original as specified functions for the endpoint
<dael> AmeliaBR: There are wpt tests that do it one way and someone expected the other. Not sure who does what
<dael> dbaron: This can influence transitions, like if you reverse when it's filling you might get different behavior. I've seen that in the past, though maybe rules have been fixed to avoid some of those cases
<dael> smfr: I wouldn't expect function upgrading for animation would effect serialization.
<dael> AmeliaBR: The issue is specifically about individual transforms and upgrading the none keyword. Not sure how it compares to functions in transform property. I would expect consistancy
<dael> dbaron: I was thinking of transform property, not functions.
<dael> AmeliaBR: My fault for skimming too quick
<dael> smfr: I understand now the endpoint there's ambig. about if you use upgraded functions
<dbaron> s/not functions/not individual transform properties/
<dael> TabAtkins: Individual transform properties, given the previous resolution that we should serialize to lowest state I think this answer the question. not for none but the ones that are 3d ot 2d there is an upgrade in the middle. If a none value should serialize as the null value or not when it's an endpoint
<dael> astearns: We should resolve on the endpoints not upgrading first?
<dael> AmeliaBR: There is a switch inbetween a none vlue and any other value has side effects. Despite previous resolution actual transform side effects are clearly defined. translate: 0 0 has side effects that translate: none does not. Can't just ignore that as a rule
<dael> AmeliaBR: If you're in an animation from a transform to antoher value the side effects persist as long as the animation. Makes sense as long as animation persists you have an explicit value instead of none
<dbaron> +1 to what AmeliaBR (IRC) just said
<dael> TabAtkins: Agree. If animation is active we should preserve that there is a transform b/c none has a lack of side effects
<TabAtkins> https://github.com//issues/3290#issuecomment-539719709
<dael> TabAtkins: Further issue is ^
<dael> TabAtkins: There's an example where one endpoint has non-normalize rotation, but during animation we do axis normalization. If it's active do we return normalized or specified non-normalized? Fine with consistent where when animation is running we report the animation's value.
<dael> smfr: Does WebANimations have soething to say?
<dael> TabAtkins: Yes, it has to report if there is an active animation. NOt sure if it has details about this issue. It knows if an animation is running
<dael> smfr: May be a case where we jsut want consistency
<dael> TabAtkins: Agree, everything except none case is consistency. I think that leans us to take value animation is working on, not the endpoint value
<dael> smfr: Sounds fine to me
<dael> astearns: Prop is we return the values the animation is working on while the animation is going and that includes the endpoints per the definition in web animations
<dael> astearns: Any concerns with this change?
<dael> astearns: Objections?
<dael> RESOLVED: We return the values the animation is working on while the animation is going and that includes the endpoints per the definition in web animations

[dbaron]

Chromium has been fixed in https://crrev.com/19620452a45a851f38799bcc2bd5ddb9d5b120ac and https://crrev.com/5f7f67e5a029e564215b859fcab1fb4de740ebbb .

I don't think there are any transforms spec changes required here. But it's possible that web-animations changes are needed, so relabeling accordingly. (Though maybe #4378 already covers that?)