contradictory tests covering animation of individual transform properties

[dbaron]

While trying to fix test failures in individual transform properties in Chromium in preparation for enabling them, I found a set of tests that I think are contradictory, and I wanted to double check with other folks involved that I'm fixing them in the correct direction.

---

On the one side, there are the tests that Chromium fails in the files (originally written in #6790 by @ericwilligers):

• rotate-interpolation.html
• scale-interpolation.html
• translate-interpolation.html

These tests assert that when animating between a none and a non-none value, the spec's statement that:

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

applies when reading the result of getComputedStyle at the endpoint (and that 0px, 0deg, or 1 is returned rather than none).

---

On the other side, there are the tests that Gecko fails in the files (originally added in #21000 by @shengha2):

• scale-composition.html
• translate-composition.html (for which bug 1607313 was filed when the test was added)

Some of these tests test whether a replace none at one of the endpoints of an animation yields a getComputedStyle result of none or of the appropriate non-none value. Some of them test an underlying value of none with an add none at one of the endpoints. The tests assert that the result is none but Gecko (and Chromium when patched to run interpolation code fully when at endpoints) produce a non-none value.

---

I think also the tests that Chromium fails in:

• rotate-composition.html

fall into the first group in terms of what the current expectations are, despite having been added in the second group.

---

My impression is that the Gecko results are probably correct for all sets, which would require changes in both Chromium (which hasn't yet shipped these properties -- but that's what I'm working on) and WebKit (which has). I think the spec text is quite clear for the interpolation part and it was also discussed explicitly in w3c/csswg-drafts#3290. However, I don't think I can point to specific spec passages that cover the add and replace parts of this in the second group of tests.

I'm curious if others agree this is the correct direction.

I'm happy to make the necessary changes to the tests if others agree; I think I already have all of the changes written.

cc @birtles @BorisChiou @emilio @graouts @kevers-google

[emilio]

cc @hiikezoe

[hiikezoe]

I can't think of any reasons why we don't apply the replacement rule for compositions as well. That said, the spec text might be a bit ambiguous about when the replacement should happen.

IIRC, in Gecko it happens during computing interpolations (or additions or accumulations), So

div.animate({ translate: ["none", "100px"] }, { duration: 10000, composite: "add" });
div.animate({ translate: ["none", "none"] },  { duration: 10000, composite: "add" });

This would produce translate: 0px at 0s. If the second animation's composite value is "replace", it would produce "none", FWIW.

Though I didn't get involved either in the spec issue or in the bug, so I might be missing something.

[birtles]

Right, I think there's possibly some confusion about when the replacement described in CSS Transforms 2 happens.

We have a resolution for interpolation behavior in w3c/csswg-drafts#3290 (comment) where I think what we were trying to say is, "You can't just skip interpolation and use the specified values for the endpoints when the progress is 0% / 100% -- you always need to do interpolation".

Web Animations seemingly lets you use the keyframe endpoints "as-is" when the progress is less than 0% or greater than 100% since there's nothing to interpolate with then (see steps 12 and 14 of The effect value of a keyframe effect) however, that procedure uses the computed keyframes so we're still not using specified keyframe endpoint values as-is. Perhaps the promotion of "none" to "0px" needs to happen when we calculate computed keyframes?

Regarding WPT, I believe @BorisChiou fixed some of the tests to align with the above resolution in Gecko bug 1506746 but I don't think that bug covered the *-composition.html files, only the *-interpolation.html files.

However, given the way composition is defined (see step 13 in The effect value of a keyframe effect and Calculating the result of an effect stack) it appears to me the *-composition.html tests are wrong.

e.g. for the test Compositing: property <translate> underlying [none] from replace [0px 40px 60px] to replace [none] at (1) should be [none] in translate-composition.html, in the absence of composition, interpolating from [0px 40px 60px] to [none] at 100% should yield 0px, and so adding the replace composition operator (which is the default anyway) should not change that.

[dbaron]

@birtles (and others): Do the test changes in #30807 (which is an auto-generated PR based on my work-in-progress Chromium change) match what you would expect? (I'd at least note that one of the changes in there is the one that @birtles mentioned explicitly.)

[dbaron]

I think this is fixed by #30807, although if somebody knowledgable wants to check that the current tests look correct, that would be appreciated.