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

Hi Mike,

Sorry about the delay. I added a few comments below.

(2014/03/15 0:02), Mike Swanson wrote:
>> (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.

The startTime is currently readonly. The idea is that the parent sets it 
and we just expose it for reflection purposes. If it were mutable we'd 
have to define the behavior if the application overwrote the value and 
the parent group wanted to update it. If the application wants to shift 
the items backwards and forwards they can use 'specified.delay'.

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

I think the behavior is well-defined in the face of gaps. The fill mode 
applies for each child independently of its siblings and whether there 
are gaps or not. We don't have a 'fill to next sibling' mode.

Thanks again Mike,

Brian

Received on Wednesday, 19 March 2014 09:14:10 UTC