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

Brian:

Responses inline...

> -----Original Message-----
> From: Brian Birtles [mailto:bbirtles@mozilla.com]
> Sent: Friday, March 14, 2014 12:16 AM
> To: Mike Swanson; public-fx@w3.org
> Subject: 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.

You didn't misunderstand. My original implementation relied on mutable a
previousSibling property. However, once I realized that my group needs
included only sequential and parallel group types, I updated it to include
the dynamic nature I described.

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

I agree that I've misused previousSibling (as it wouldn't be possible to
walk backwards through one of my parallel groups using previousSibling
alone...they'd all be null). I plan to update my implementation to reflect
this.

Regarding the possible addition of another property to reflect a
previousAnimation/previousTimedItem, I'm becoming less convinced of this
idea for Web Animations, especially if it's anticipated that other group
types may be necessary. For those cases, the ability to purposely schedule a
mutable startTime seems to make more sense.

However, something about the fact that there could be "gaps" between
scheduled TimedItems doesn't feel right to me. If I created a new group type
that scheduled TimedItems sequentially by adding one second to the endTime
of the prior TimedItem, what is the correct behavior in the one second gap
between each TimedItem? Would it simply be an extension of the prior item's
endDelay? Or the next item's initial delay? What is the correct fill mode in
that gap? By having a previousAnimation/previousTimedItem, gaps are
inherently eliminated, and all time is defined.

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

I like the idea of replacing 'sequential: true' with something more
flexible, but at that point, I start to wonder if the current proposal of
two different group types makes more sense. With the possibility of new
group types that schedule startTimes in different/unique ways, I think using
types to define new behavior is the way to go. I still struggle with the
"gap time" concern I mentioned earlier, but it sounds like you're aware of
other group types that need to be accounted for.

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

In my implementation, there is a 'sequential' Boolean on my single group
type. While it can be set in the constructor as a convenience, it is also a
mutable property. So, yes, you can easily "flip" between a group with
parallel and sequential timing. I'm not sure how useful this is in practice,
beyond interactive editing applications. Because the calculation of a
TimedItem's startTime and previousSibling (which I'll be renaming to
previousAnimation/previousTimedItem in my implementation) is dynamic, there
is no other work to be done to "reschedule" anything.

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

I normally prefer most of my classes to be immutable (where they can be),
but I'm trying to free my mind and adopt the most-things-are-mutable spirit
of many elements of the Web Animations spec. So, I extended it to groups
too. :-)

> But nothing overly substative. I'll think about this some more.
> 
> Thanks again Mike,
> 
> Brian

Received on Friday, 14 March 2014 16:03:21 UTC