[web-animations] TAG Issue: Wrong leveling

Hi list,

I'm attempting to address some of the TAG's feedback regarding Web
Animations (
https://github.com/twirl/spec-reviews/blob/master/2013/10/Web%20Animations.md),
which I reproduce below:

----
ISSUE: Wrong leveling

Relations between AnimationPlayer, TimedItem and Timing interfaces present
very uncommon patterns: copying writable attributes from Timing to
associated TimedItem as read-only attributes, setter on
AnimationPlayer.source which calls methods, etc.

It seems like a design problem. Representing "computed" timing should be
separated from grouping functionality and delegated to some kind of
dependent entity (like getComputedStyle in CSS is separated from .style
property).
----

The problem, as far as I understand it, is that the TimedItem constructor
is given a TimingInput dictionary that initializes a Timing object.
However, from this Timing object, some values are derived and added
directly as properties on the TimedItem object. Some of these values are
straight copies while others are computed.

The Timing dictionary has the following properties:
double delay, double endDelay, FillMode fill, double iterationStart, double
iterations, double or DOMString duration, double playbackRate,
PlaybackDirection direction, DOMString easing.

>From these properties (and other context), the following timing properties
on TimedItem are calculated:
double startTime, double duration, double activeDuration, double endTime

Furthermore, the fill is modified before use if specified as "auto" (the
default), but the result of this is not exposed.

We discussed two different approaches to resolving this issue during our
recent telcon:

(1) Copy / compute timing values into another member of TimedItem
(.computed? .computedTiming?) with type ComputedTiming. Ensure that
ComputedTiming is a subclass of Timing, so that it can be used directly as
an input to the Animation constructor.

This would mean that computed would contain:

interface ComputedTiming {
  attribute double delay; // copy of Timing.delay
  attribute double endDelay; // copy of Timing.delay
  attribute FillMode fill; // computed from Timing.fill
  attribute double iterationStart; // copy of Timing.iterationStart
  attribute unrestricted double iterations; // copy of Timing.iterations
  attribute unrestricted double duration; // computed from Timing.duration
  attribute double playbackRate; // copy of Timing.playbackRate
  attribute PlaybackDirection direction; // copy of Timing.direction
  attribute DOMString easing; // copy of Timing.easing

  attribute double startTime;
  attribute double activeDuration;
  attribute double endTime;
}

We could possibly also move two further timing-related members from
TimedItem to ComputedTiming: localTime and currentIteration. Finally, we
may additionally expose timeFraction on ComputedTiming.

(2) As above, but provide a getComputedTiming method to expose the
ComputedTiming values rather than exposing them as a property.

If we did this, then getComputedTiming could be:
(a) a method on window (cf getComputedStyle)
(b) a method on Timeline
(c) a method directly on TimedItem

Are there any preferences? I think we're like to go with option (1) unless
there are good reasons for a getComputedTiming() method.

Cheers,
    -Shane