Re: [web-animations] Re: Web Animations Spec Feedback

Hi Mike,

Thanks for your mail. I misunderstood your proposal--I thought 
previousSibling was mutable and the flag to the constructor simply 
influenced its initial setting.

(2014/03/14 14:05), Mike Swanson wrote:
> Regarding 'previousSibling' (which I had erroneously referred to as
> 'priorSibling' in my original message), I have attached a diagram that shows
> how I view the 'previousSibling' relationships in an animation group
> hierarchy. It's possible that I'm not conforming to the true definition of
> 'previousSibling' as it relates to the spec, and if that's the case, feel
> free to call it 'previousAnimation' if it makes more sense. Regardless of
> its name, having a reference to the prior animation makes it easy to
> dynamically infer a TimedItem's 'startTime.'

Yes, I think previousSibling is useful for traversing groups and I'm 
afraid that if we end up using it for sequencing we'd end up needing 
both previousSibling and previousAnimation?

> It's worth noting that I have a single AnimationGroup class that has a
> Boolean that indicates whether it's sequential, so this is a trivial test.
> It would get a bit less elegant if you had to check the class of the parent
> (as in the current proposed model of two different group classes).

I think at very least we'd want to replace 'sequential: true' with 
'type: "sequential"'. Otherwise we'd have trouble adding other types of 
groups. For example, suppose we added SMIL's exclusive groups then we'd 
have to define the behaviour when both 'sequential' and 'exclusive' are 
true.

> The benefit of the dynamic 'previousSibling' and 'startTime' properties is
> that my animation classes and groups can remain mutable, and all of the
> dynamic calculations continue to work. There is no "re-setting" or
> recalculating of startTimes to deal with. I can also easily move from
> sequential to parallel group behavior dynamically with the setting of a
> single Boolean on my group class.

I don't quite understand what remains mutable. Do you mean that you can 
change the type of the group dynamically? Is there anything else?

I have a few aesthetic reasons for preferring group types be immutable 
(future group types may take additional inputs that govern their 
behaviour which would be non-sensical if the group type changed; code 
where the group name is in the interface seems more readable and named 
constructors are discouraged in WebIDL; better mapping to element names, 
etc.)

But nothing overly substative. I'll think about this some more.

Thanks again Mike,

Brian

Received on Friday, 14 March 2014 07:16:51 UTC