[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).