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

Hi Mike,

Thanks for your mail and diagram. I think it's important to remember 
that the two TimedItems in the diagram may be animations targeting 
completely different elements or properties.

For example, the first timed item might be an animation that targets the 
'left' property with a forwards fill. The second timed item might be an 
animation that targets the 'top' property with a backwards fill. During 
the 'gap' *both* are applied.

Furthermore, while the first animation is running, the backwards fill of 
the second animation still applies. Likewise, while the second animation 
is running the forwards fill of the first animation still applies. 
(Whether they apply beyond these points depends on the fill mode of the 
parent group.) That is, fill modes always overlap, even when there is no 
gap.

In the situation where the two timed items are animations that target 
the same property on the same element, they are combined using the 
animation stack. If the second animation had a backwards fill and had a 
replace composition mode it would effectively hide the first animation 
since it has a later start time. There are a number of ways to avoid 
this (shuffling the tree and using delays; using a forwards fill on the 
first animation instead of a backwards fill on the second; using 
additive animation; etc. etc.). We don't have 'fill until next sibling / 
fill from last sibling' however, or at least not yet.

Have I understood the issue correctly?

Thanks,

Brian

(2014/03/20 7:28), Mike Swanson wrote:
> Brian:
>
> Perhaps I don't fully appreciate the fill modes, and if that's the case, I'm
> happy to hear that "it's handled," and I'll have faith. :-)
>
> In the meantime, to better explain my question about gaps, I've attached an
> illustration. Imagine that I've created a new group type that is free to
> schedule TimedItems with "gaps" between the endTimes and startTimes. If I
> understand those times correctly, they incorporate both the initial delay
> and the end delay. If two successive items have competing fill modes, what
> is the behavior of the value during the gap?
>
> The parent animation group is actively playing, so its fill modes wouldn't
> apply to the gap, right? Is the result just the result of the composition?
>
> Mike
>
>> -----Original Message-----
>> From: Brian Birtles [mailto:bbirtles@mozilla.com]
>> Sent: Wednesday, March 19, 2014 2:14 AM
>> To: Mike Swanson; public-fx@w3.org
>> Subject: 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 Thursday, 20 March 2014 01:57:30 UTC