Re: [web-animations] TAG Issue: Wrong leveling

Hi Shane,

Thanks very much for following up on this!

(2014/05/05 10:00), Shane Stephens wrote:
 > ...
> 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

With the additional qualification that fill is never "auto" here.

(These should all be readonly too. Or, actually, we might need to define 
TimingReadonly and have both ComputedTiming and Timing inherit from it. 
In Timing we would mark each of the attributes "inherit".[1] Of course, 
if we go with getComputedTiming and make it return a dictionary, we 
don't need to worry about this.)

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

I think we should do that.

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

I slightly prefer getComputedTiming because:

   a) It has a clear parallel with getComputedStyle which every web dev 
knows (or ought to).
      The closest parallel to a computedTiming member is currentStyle 
which is non-standard and a pattern we should probably discourage.

   b) It makes the timing objects completely stateless which may allow 
for reuse or at least suggests a better separation of concerns.

The main difficulty, as I see, is that getComputedStyle returns a live 
CSSStyleDeclaration object which apps may hang on to and query as it 
changes.

We *could* make getComputedTiming return a live ComputedTiming object 
but making it return a dictionary instead would:

   a) allow adding a parameter in the future that is, for example, the 
timeline time and returning the computed time at that moment e.g. 
anim.getComputedTime(2000)
   b) simplify implementation

For (a), perhaps we could just add getComputedTimingAt in future which 
returns a dictionary?

As for (b), it's hard for me to gauge the relative importance of making 
the API lightweight and simple vs matching the behaviour of 
getComputedStyle here.

I guess I'm leaning towards something like the following:
(Taking the liberty of renaming Timing to AnimationTiming at the same time)

   interface AnimationTimingReadonly {
     readonly attribute double delay;
     ....
   };

   interface AnimationTiming : AnimationTimingReadonly {
     inherit attribute double delay;
     ...
   };

   interface ComputedAnimatingTiming : AnimationTimingReadonly {
     readonly attribute double? localTime;
     readonly attribute double? timeFraction;
     readonly attribute unsigned long? currentIteration;
   };

   interface TimedItem {
     readonly attribute AnimationTiming timing;
     ...
   };

   partial interface Window {
     ComputedTiming? getComputedTiming(TimedItem item)
   };

[1] http://heycam.github.io/webidl/#dfn-inherit-getter

Received on Wednesday, 7 May 2014 02:00:21 UTC