This implements the following change to the Web Animations specification:
19b6c33cee
The background to that change is described in the corresponding spec issue:
https://github.com/w3c/web-animations/issues/201
MozReview-Commit-ID: GGA64LG5vT
This is in preparation for further changes to these files later in this patch
series.
In particular this patch:
* Moves some code to more modern Javascript that should be easier to read and
maintain
* Makes the tests more strict about when active/after values are specified
- If the timing parameters mean there is no active phase, the test should not
specify a value to test for that phase. If there *is* an active phase, the
test must provide a value to test (if it does not the test will fails when
it compares against the undefined value).
- Likewise for the after phase
This should make it a little easier to incorporate testing the playbackRate.
MozReview-Commit-ID: 17vihK5RSbu
We don't however, use arrow syntax for local functions that act as class
constructors since they don't want the lexical this that arrow functions use.
MozReview-Commit-ID: FuVhHIBFZrE
This naming is recommended by [1] and from a random sampling of tests in
web-platform-tests it seems like most test don't use this, only tests that are
split over multiple files.
This "processing a keyframes argument" section is quite large so I intend to
split the tests up into a number of files to cover:
* Tests for property access
* Tests for easing
* Tests for offset
* Tests for composite
* Tests for equivalent forms
[1] http://web-platform-tests.org/writing-tests/general-guidelines.html#file-paths-and-names
MozReview-Commit-ID: JW2m50UnsKv
This seems to be standard JS style recently (as used in prettier etc.): Use
spaces to separate the { and } from the properties (but not for arrays).
MozReview-Commit-ID: FRkFRwwcJJh
* We should refer to reading or accessing properties, as opposed to
"considering" them.
* We should use "property-indexed" consistently.
MozReview-Commit-ID: ItCE4g8LmOC
There is a test that assumes that an offset specified on a property-indexed
keyframe is applied to all generated keyframes but that behavior is not (yet)
specified.
This behavior will be specified in [1] but until that happens it seems invalid
to test for it. Furthermore, when that is specified we will need much more
thorough tests than this one.
[1] https://github.com/w3c/web-animations/issues/148
MozReview-Commit-ID: HUUw88dg2P7
for...of is generally preferred over forEach since it is a little easier to read
and allows using 'break' and 'continue'. Furthermore it is supported in all
major browsers. (It also makes wrapping one of the long lines in this file
easier.)
MozReview-Commit-ID: 1BuoW0QSxaG
Gradually we plan to move all these tests to ES6 (or at least the subset
supported by all UAs that are likely to implement this spec) so while we are
touching this file we update a few uses of 'var' to let/const.
MozReview-Commit-ID: 45OJyXmUzKu
KeyframeEffectReadOnly may disappear (see [1]) and is only needed for CSS
Animations and CSS Transitions so in that sense KeyframeEffect is more basic
(despite being a subclass of KeyframeEffectReadOnly) so we should prefer it to
KeyframeEffectReadOnly.
Furthermore, as the comment at the start of the file suggests, we should
consistently use the same method for testing these procedures. We currently use
the KeyframeEffect constructor because it is more direct and basic.
[1] https://github.com/w3c/web-animations/issues/185
MozReview-Commit-ID: LBrlfzyn2Ch
And also drop the slightly misleading and redundant comment about the procedure
that this test covers (it covers *both* the "process a keyframes argument"
procedure and the "process a keyframe-like object" subprocedure).
MozReview-Commit-ID: 9lzx4rCj20o
According to the spec, if one of the matrices for transform interpolation is
non-invertible, the used animation function must fall-back to a discrete
animation. Add wpt tests so we can ensure the web compability for this behavior.
Note that we don't add 'discrete' type for transform property in property-list.js.
Because the 'discrete' type also tests discrete addition and accumulation,
however, the fallback behavior is just for interpolation and accumulation, not
for addition. So, we add tests in each part of transformListType in property-types.js.
One test is failing in Gecko, so annotate it for Gecko.
MozReview-Commit-ID: 3JGvgqbBqZp
This test aims for forcing the two mismatched transforms to be decomposed into
matrix3d before interpolation. To do so, we need to:
1. make 'From' and 'To' to be two mismatched transforms,
2. at least one of the two transforms has to be a 3D transform.
In this way, we not only test the interpolation, but also test the correctness
of 3D matrix decomposition.
MozReview-Commit-ID: FAKu6GFVZRm
