a) Is the parameter to Document.timeline.createPlayer optional?
Yes, since this allows you to set up the players (with their start times) and set (schedule) the timed items later.
i.e. Timeline.createPlayer(optional TimedItem item)
b) Is Player.play(TimedItem item) needed?
No, not if Player.timedItem is writeable. Making Player.timedItem writeable allows you to substitute in another animation whilst maintaining current time / playback rate etc.
If you want to reset then just set Player.startTime to Timeline.currentTime (or just cancel and createPlayer with the timedItem).
c) What does cancel() do?
Cancel sets timedItem to null.
Discussed whether unpause() should be called play() but agreed it should stay unpause() because the semantics are different to HTMLMediaElement’s play() (e.g. if the start time is in the future, calling this method should NOT make the thing start, it simply unpauses if you’ve paused). Also: unpause() has no effect without calling pause() first, so it's an appropriate name.
Also discussed whether Player can control multiple TimedItems but agreed that this is not necessary since you can just use a ParGroup for that.
Also discussed how audio/video is part of this and decided for a “MediaRef” object that is also a TimedItem. MediaController could also be referenced from a “MediaRef” object — Shane is going to have a go at sorting through the details.
2. SHOULD IT BE getComputedTiming() OR JUST computedTiming?
After some fairly intense deliberations we’ve decided to go with option 1 for now. We will clearly mark in the spec as an issue some of these alternatives and see what feedback we get.
There was also the suggestion of gathering metrics from the polyfill to see which functions are used most often so we can optimise the API accordingly.
3. MORE COMPLEX TimingFunctions
Some other APIs have many many timing functions. We don't want to define all of these in Web Animations, and certainly not in the first version. However, many authoring tools will want to export different effects (e.g. bounce effects etc.).
It would be useful if the baseline version of Web Animations had a means of representing such timing functions.
There is a proposal to extend SplineTimingFunction so that it can take more than one segment. This would allow most timing functions to be approximated. Also, all implementations will be required to implement the maths for SplineTimingFunction anyway so it should be minimal implementation overhead to support multiple segments.
However, we need to consider what constraints are necessary on the control points in order to ensure that the resulting curve produces a function (i.e. there is one and only one output value for each input time).
One strawman proposal was to take multiples of four numbers where the sequence is something like this:
<first point is 0,0>
[0,1]: first control point
[2,3]: second control point
[4,5]: end of first segment
<first control point of second segment is the reflection of [2,3]>
[6,7]: second control point of second segment
<end point is 1,1>
But this makes it hard to represent curves with sharp points (such as bouncing). We need to look into what limitations are needed on the input values.
Dmitry proposed an approach that takes 3 points for all segments except for the last, which takes 2. (0, 0) forms the first point for the first bezier, (1, 1) forms the last point for the last bezier. The final point of each bezier forms the first point of the next bezier.
The final points (i.e. the 3rd, 6th, 9th, etc.) (or maybe all the points?) must be monotonic increasing in x.
This approach allows for sharp corners at the cost of more difficulty in producing smooth curves; as the interface is primarily for tool designers this increase in difficulty doesn’t matter.