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

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