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

|  From: Brian Birtles
|
|  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).

This is putting much burden on the other working groups to have this 
correctly defined. Since the use case is valid and spread accross CSS and 
SVG, liveness should probably be implemented somehow in the WebAnimation 
layer.

That being said, I agree that forcing script authors to use templates is 
somewhat a bad idea. Creating a single independent animation should be 
supported natively and the newly proposed 'Anim' constructor seems to fit 
that need perfectly.




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

I just read the latest meeting minutes. On that matter, I'm afraid you can't 
rely on JS prototypes to implement liveness.

(1) WebIDL interfaces are static and are not editable over time (this means 
we can't add own getters/setters to an AnimInstance during makeIndependent 
calls).

(2) The JS prototype chain is something that's not available to WebIDL 
because this is a JS engine's projection (real implementations are most 
likely to use traditionnal C++ inheritance). You can read more about the JS 
projection of WebIDL interfaces here: 
http://www.w3.org/TR/WebIDL/#ecmascript-binding

However, I would not claim I'm a WebIDL expert; since the only editor of the 
specification works at mozilla, I would advise you to prepare a list of 
specific questions and hand them over to him. Making educated guesses is a 
good way to kickstart the discussion but taking decisions requires a bit of 
trustable knowledge.




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

If you look at the conventions in use, classes whose name ends with 
'Prototype' are automatically-generated classes by the JS projection to 
store the class functions and property descriptors.

In the general case, if you have an HTMLImageElement class exposed to JS, 
you have:
- HTMLImageElement === the constructor function (std function)
- HTMLImageElementPrototype === (property descriptors for HTMLImageElement : 
'src', 'width', 'height', ...)

- the 'prototype' property of 'HTMLImageElement' is set to an 
'HTMLImageElementPrototype' instance.
- HTMLImageElementPrototype is not instanciable

Therefore, I suspect that the Anim class (i.e. current AnimInstance) will 
already define an AnimPrototype class to store its property descriptors and 
AnimTemplate would be a better choice.




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

Actually, the element itself can be the timeSource, if it implements the 
interface. I initially made the interface based on what is already implement 
on all HTML media elements. This would be a no-op to implement a 
such-defined TimeSource interface on them because everything is already 
there. Granted, using a property to expose an external TimeSource instance 
is also posible.

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

In my head, the time cascading behavior would be done through a 
"InheritedTimeSource" which would basicly return the value of another, 
wrapped TimeSource. However, with a concept of timeDrift and the like, it 
would be possible to 'pause' or 'changeSpeed' a InheritedTimeSource even if 
it inherits its time from the TimeSource of another element.




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

I support the idea.

Received on Friday, 3 August 2012 08:07:16 UTC