W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2014

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

From: Brian Birtles <bbirtles@mozilla.com>
Date: Wed, 02 Jul 2014 15:08:09 +0900
Message-ID: <53B3A1C9.3040109@mozilla.com>
To: Domenic Denicola <domenic@domenicdenicola.com>, "public-fx@w3.org" <public-fx@w3.org>
CC: Cameron McCormack <cam@mcc.id.au>, Boris Zbarsky <bzbarsky@MIT.EDU>
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.)

* 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
Received on Wednesday, 2 July 2014 06:08:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:50 UTC