Re: [web-anim] API feedback

Hi François,

(2012/08/03 17:06), François REMY wrote:
> |  (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.)
>
 > ...
>
> 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.

Yes, Cameron's been very helpful in clarifying a number of the issues 
you mentioned.

For those reasons I'm not looking at exploiting Javascript's prototype 
chain here.

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

As far as I can tell, this is specific to Safari (in Chrome, 
document.createElement('img').__proto__ gives me HTMLImageElement).

Nevertheless it's probably better to avoid confusion between AnimProto 
and Anim.__proto__ etc and just go with AnimTemplate as you suggest.

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

Ok, that's good. This was the direction I originally wanted to go but 
then I thought it wasn't possible since WebIDL doesn't support MI. I 
didn't know about the implements keyword.

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

I think if the time source behaviour lives in the items themselves we 
don't need an InheritedTimeSource. We can just use the currently 
specified behaviour where time input time comes from the parent group.

Thanks again,

Brian

Received on Monday, 6 August 2012 02:51:16 UTC