Re: [web-animations] Readonly interfaces and inheritance: seeking advice

On Wed, Jul 2, 2014 at 8:08 AM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Dear Domenic / public-fx,
>
> Having seen the recent discussion on public-script-coord about
> DOMRectReadOnly[1], a pattern I blindly copied into Web Animations last
> week,[2] I wonder if you can advise how we should arrange timing objects in
> Web Animations?
>
> Currently we have the following arrangement:
>
>   interface AnimationTimingReadOnly {
>     readonly attribute FillMode                           fill;
>     readonly attribute (unrestricted double or DOMString) duration;
>     ...
>   };
>
>   interface AnimationTiming : AnimationTimingReadOnly {
>     inherit attribute FillMode                           fill;
>     inherit attribute (unrestricted double or DOMString) duration;
>     ...
>   };
>
>   interface ComputedAnimationTiming : AnimationTimingReadOnly {
>     readonly attribute unrestricted double timeFraction;
>     ...
>   };
>
>   // Abstract interface inherited by Animation, AnimationGroup etc.
>   interface AnimationNode {
>     readonly attribute AnimationTiming         timing;
>     readonly attribute ComputedAnimationTiming computedTiming;
>     ...
>   };
>
>   // Passed to the ctor of Animation, AnimationGroup etc.
>   dictionary AnimationTimingInput {
>     FillMode                           fill = "auto";
>     (unrestricted double or DOMString) duration = "auto";
>     ...
>   };
>
> A few points of explanation:
>
> * None of these have constructors. I'll fix that (except AnimationNode
> which is an abstract interface inherited by Animation, AnimationGroup etc.)
>

Don't do that just yet.
Making them constructable will push their name in the global namespace. As
you know, exposing a new name is a Big Deal. It's also unclear if anyone
will call that constructor so this is just for theoretical purity.
Instead, just mark them as [NoInterfaceObject]


> * Unlike DOMRectReadOnly, the members of AnimationTimingReadOnly are
> actually used as-is by ComputedAnimationTiming so it's slightly different
> in that regard.
>
> * What we are *trying* to do here is expose both the specified timing
> (which is input/output) and calculated timing (which is purely an output).
> Many of the fields are the same but sometimes the range of values differs.
> For example, the |duration| member of a returned ComputedAnimationTiming
> object will always be a double, not a string. Likewise, the |fill| value
> will never be "auto".
>
> * We've also added some attributes onto ComputedAnimationTiming that
> aren't on AnimationTiming(ReadOnly) like timeFraction etc. Perhaps they
> don't belong there since they're more about *current* state rather than the
> result of resolving timing parameters but maybe it's ok?
>
> Questions:
>
> * What do you think of this hierarchy? Is there a better way of keeping
> AnimationTiming and ComputedAnimationTiming in sync without introducing
> AnimationTimingReadOnly?
>
> * Or should computedTiming just return a snapshot object with different
> object identity every time it changes? Perhaps a method that returns a
> dictionary object?
>
> * I guess AnimationNode.timing should not be readonly? I think making it
> [Replaceable] might be problematic from a performance point of view but if
> we define setting as doing a member-wise copy is that idiomatic?
>
> For example, is this better?
>
>   [Constructor (AnimationTimingInput timing)]
>   interface AnimationTiming {
>     attribute FillMode                           fill;
>     attribute (unrestricted double or DOMString) duration;
>     ...
>   };
>
>   dictionary AnimationTimingInput {
>     FillMode                           fill = "auto";
>     (unrestricted double or DOMString) duration = "auto";
>     ...
>   };
>
>   dictionary ComputedAnimationTiming : AnimationTimingInput {
>     unrestricted double timeFraction;
>     ...
>   };
>
>   interface AnimationNode {
>     attribute AnimationTiming timing;
>     ComputedAnimationTiming   getComputedTiming();
>     ...
>   };
>
>
> We'll probably have similar questions with regards to AnimationPlayers and
> AnimationNodes. We talked about making AnimationNodes generated from CSS be
> read-only so you'd have to clone it if you wanted to modify it rather than
> ending up in a situation where the object is partly live due to being
> partially overridden by script. That's a separate discussion but your
> suggestions to the above will probably help guide that.
>
> Best regards,
>
> Brian
>
> [1] http://lists.w3.org/Archives/Public/public-script-coord/
> 2014AprJun/0267.html
> [2] http://dev.w3.org/fxtf/web-animations/#idl-def-AnimationTimingReadOnly
>
>