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

Brian:

Indeed, you have understood the issue as I explained it. I was referring to
the case where the target properties were the same. It makes sense that the
animation stack  would composite the values. Thank you for taking the time
to elaborate.

Mike

> -----Original Message-----
> From: Brian Birtles [mailto:bbirtles@mozilla.com]
> Sent: Wednesday, March 19, 2014 6:57 PM
> To: Mike Swanson; public-fx@w3.org
> Subject: 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 02:12:00 UTC