[web-anim] API feedback (was: [css3-animations] time sources, videos and storyboards)

Hi François,

Thanks so much for your feedback! It's very much appreciated. I'll 
respond below. I'm CC'ing public-fx since you said that was ok.

François REMY wrote:
> Here's my first remark about the specification (more specifically,
> about [[5. Creating animations]]).
 >
> ...
>
> I personally don’t like the fact that the linked instance has been
> silently tranformed into an independent animation during a property
> set, as this is error prone. I think, but maybe others would not
> agree, that the set operation should trigger an exception if
> ‘makeIndependant’ has never been called before.

Lately we've been discussing getting rid of liveness altogether. It's 
mostly required for CSS and SVG and I've been suggesting that CSS and 
SVG will already be doing their own bookkeeping so they can implement 
the liveness behaviour they require (e.g. reflecting changes to 
properties/attributes across to all animation instances).

Your suggestion about throwing an exception and requiring an explicit 
call to makeIndependent is something I hadn't thought of. I prefer that 
to what we currently have. I've added it as another proposal to consider 
at our next meeting.[1]

(Speaking of meetings, all our minutes are archived along with meeting 
times.[2] We currently use Google Hangout for the discussion but I'd 
like to move to something others can more easily join in. Until I work 
that out, let me know if you want to join in.)

> BTW, here are some thoughs about the naming convention :
>
> - I would prefer if the “Anim” type was called “AnimTemplate”.

Originally this is what we named them, but we realised that from script 
you much more often refer to AnimTemplate than Anim so we thought it 
should be shorter.

However, last week we resolved to add a global function to avoid the 
need to explicitly create a template for simple cases. As a result, 
authors should have to type the name of the interface much less often.

I had already added to the agenda for the next meeting renaming these 
back. I was proposing renaming Anim to AnimProto since that might be a 
more natural analogue for Javascript programmers but I think 
AnimTemplate is good as well. What do you prefer?

Obviously, in the process we would also rename AnimInstance to just Anim 
and do similar renaming for the group classes.

One further conversation we've had recently is removing the template 
approach altogether--just allow Anim to have no targetElement, then 
clone it and assign an element/startTime/parentGroup etc. Something like 
cloneAndRun(). It would simplify the API a lot. Still, it's just an idea 
at this stage and needs more thought.

> - I would prefer if the “animate” and “animateLive” functions were
> called “createInstance(s)” and “createLinkedInstance(s)” as it better
> reflects what’s going on.

Ok, that's interesting. I like the "linked" term better than live.

I think I prefer the animate verb though since the process actually 
makes the thing run--i.e. adds to a group, assigns a target element, 
sets a start time etc. Nothing more is required to get the animation 
going. 'Create' sounds to me like you've made the instantiation but it 
still needs to be kick-started?

Perhaps we can revisit this naming after we settle on the bigger issues 
of how to approach liveness and templating.

> - I would also rename “animate*WithParent(el,group)” in to
> “create*Instance(s)InGroup(el,group)”

Sounds good to me. I've added it to my list of changes to make unless 
anyone objects.

> In the [[5.3 Instantiating an Anim]] algorithm, I see references to a
> “group” variable but it doesn’t seem to be defined anywhere; you
> probably meant “element” instead.

Yes, thank you. I'll fix that.

> (in order to add animations / video playback synchronization)
> In [[6.5 The TimedItem interface]] section, I think we should refactor
> part of the TimedItem interface into a TimeSource interface. The
> TimeSource would have no dependency on the rest of the module and
> could be implemented on HTMLMediaElement, or could be instanciated on
> its own and be shared accross multiple TimedItem. To make transition
> from HTMLMediaElement smoother I think we should actually use the name
> already used on the HTMLMediaElement interface to make the HTML WG’s
> work as simple as possible. Here’s what it would look like :
> interface TimeSource {
>
>      double currentTime { get; set; }
>      double initialTime { get; }
>
>      double playbackRate { get; set; } // equivalent of speed; precendt
> in the spec: [[7. Controlling animation playback rate]]
>
>      double duration { get; } // returns NaN if unknown or infinite
>      boolean loop { get; set; } // says if currentTime is reset to
> intialTime when it reach initialTime+duration
>
>      boolean paused { get; set; }
>      void pause() {..}
>      void play() {...}
>
>      // maybe: void seek(double time);
>
> }
> I propose to remove related concepts from the TimedItem interface and
> add a “timeSource” property to it instead. The whole “timeDrift”
> concept and the implemetation of the time-related methods would be
> refactored into a DocumentTimeSource class impelmenting the TimeSource
> interface, as it doesn’t concern the media element’s timesources.

Ok, I have to think about this a bit more.

The current plan with regards to media groups is outlined in point 4, 
here: https://etherpad.mozilla.org/lIwpKlVNd2

The time source idea is growing on me. It's a little more invasive (in 
HTML) than what is on the etherpad but HTMLObjectElement.timeSource is 
more intuitive than HTMLObjectElement.timedItem.

One concern I have is that time in Web Animations cascades down the 
hierarchy. Timed items get their input time from their parent group. 
Moving the time source to a property weakens that model somewhat (i.e. 
you have to maintain a link between a child time source and the time 
source of the parent group via the timed items). Maybe there's a way 
around that. Perhaps we just make TimedItem effectively a subclass of 
TimeSource. In that case the approach is basically the same as the one 
on the etherpad but with the addition of splitting out a simplified 
superclass.

Currently synchronising with media is a bit further down the list of 
things to do so I'd like to come back to this in a week or two.

> Another question: How do you plan to handle the case where people
> would like to have “createInstance” working with querySelectorAll in a
> dynamic way? I mean, it’s quite possible that people want to have an
> animation running for all their elements having the “zombie” class in
> a PvZ-style game. If we’re going to add WebAnimations support in CSS,
> this will be required anyway. I would say that you should watch the
> initial, live collection and listen the “element added” and “element
> removed” events in order to keep the animation instance always synced
> with the initial collection.

That's definitely an interesting use case. Currently you would realise 
that by creating the necessary style rule using the CSSOM and then 
fetching the corresponding Anim object and manipulating it via script as 
necessary. So I guess what we're talking about is a shortcut so you 
don't need to go via the CSSOM.

One question is what would be startTime for the added elements? For CSS 
Animations, that's defined (albeit in a broken way). There are a few 
options:

(a) startTime is the current iteration time of the group to which the 
timed item is added when the element is added to the list (similar to 
what CSS Animations does)
(b) startTime is the time used when createInstances/animate was 
originally called (i.e. the added elements catch-up to already running ones)

Both of those have their uses. This could potentially be layered on top 
of the underlying model with a utility method.

> About the Global Animation Stack: I think that we shall need to have
> the possibility to create a sub-stack where rules ordered according to
> any sort that may be useful to the sub-stack controller. For example,
> we need to order CSS animations by their specified order in’animation’
> property. If we add support for grouped animations and storyboards to
> CSS, we shall need to order them according to their selector
> specificity. There should be a way for the CSS/SVG engines to control
> their own stack with their own rules.

I'll let Shane comment on that since I haven't looked at this part of 
the spec recently.

Just as a heads up regarding other upcoming changes in my todo list:

* We've been talking about differentiating between effects (animations 
that you never replay / rewind / seek and which you can discard as soon 
as they finish) and content animations (e.g. cartoons that you want to 
be able to seek / replay etc.). This is a pretty fundamental change and 
will probably involve having two timelines: effectsTimeline and 
contentTimeline.
* Adding TimedItem.start() (added but not checked in)
* Adding TimedItem.stop()
* Converting exceptions to newer DOM4 style names
* Adding TimedItem.reverse()
* Removing the old Timing.reverse() behaviour
* Possibly revising pause behaviour for not-yet-started items
* Removing liveness
* Converting constants to enums
* Renaming Timing properties to make them shorter
* Adding a super class to animations can target pseudo elements as well 
as regular elements
* Adding a global Animate / Animate.effect function(s) to avoid the need 
to explicitly create a template
* Renaming Anim / AnimInstance (to AnimProto / Anim or AnimTemplate / 
Anim), likewise groups
* Adding support for variable duration
   i.e. duration: <time> | auto | %
* Adding TimedItem.clone(), TimedTemplate.clone() etc.
* Adding TimedItem.reset() to clear timeDrift (and possibly seek to 
start when called on timeline)
* Possibly add oninactive, onactive, ondirectionchange events
* Splitting out sanitizing of values (e.g. define 'effective iteration 
start' once and re-use it easily)
* Adding description of timing model properties (e.g. stateless-ness)

There's lots of other work too (the todo's, formatting etc.) but that 
should give you an idea of some changes to expect. The spec's still very 
much in flux but I'm hoping to spend most of August on it so it should 
start to firm up towards the end of the month.

Thanks again François. It's really great to have your help!

Best regards,

Brian

[1] https://etherpad.mozilla.org/bfJdTefySR
[2] http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

Received on Friday, 3 August 2012 02:35:44 UTC