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
We are gradually line the tests up better with sections in the spec. Given that
these tests are concerned with testing the "reverse an animation" procedure in
the spec (and not the API per se) they should be moved to an appropriate
subdirectory of timing-model.
We also update the test titles to make it clear that these tests are really
covering the timing model, not the API.
MozReview-Commit-ID: J5gc3HZg9qv
These should be part of the tests for the transformed distance since that is
currently the only place where they can occur.
This patch also revises the test descriptions somewhat to make it clearer what
is being tested.
MozReview-Commit-ID: D4YfAiZUBYR
The purpose of these tests appears to be to check that a linear-equivalent
cubic-bezier timing function (e.g. 'cubic-bezier(0, 0, 0, 0)') does not affect
the result such as clamping values out of the [0, 1] range.
This test really is testing the calculation of the 'transformed distance' in
the "The effect value of a keyframe effect" so we move the test there and
rework it to more clearly test what it is intended to cover.
MozReview-Commit-ID: 9sEr7MlVZKL
This set of tests are really just testing that we apply the timing function to
the animation effect so they belong in the appropriate part of the timing model
tests (and should check getComputedTiming not getComputedStyle).
I've also started to update tests to ES6 where appropriate since it seems
arrow functions, template literals, etc. are all supported on all UAs that
are implementing or likely to implement Web Animations.
MozReview-Commit-ID: 3kXao0Xi0BA
From spec <https://w3c.github.io/web-animations/#dom-keyframeeffectreadonly-getkeyframes>:
composite
The keyframe-specific composite operation used to combine the values
specified in this keyframe with the underlying value.
This member will be absent if the composite operation specified on
the keyframe effect is being used.
MozReview-Commit-ID: 8ob59Xv6DRL
