Server Notice:


Public Pad Latest text of pad 7Qo6P4kYyD Saved Dec 11, 2012

Meeting 35:
Web animations minutes, 10 / 11 December 2012
Present: Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles
1. Status update
2. Time sources
3. Groups and time windows
4. Small fry
- Finished changes to KeyframeAnimation interfaces
- Still working on adding TimeSources to polyfill, hung up on numerous bugs in existing logic.
- Implemented color handling in polyfill, thinking about Timing
- Implemented PathAnimationFunction in polyfill using SVGPathElement#getPointAtLength
- We think separating time sources from parent ownership may be a useful separation of concerns for some use cases
  - and conflating the two may be counter-intuitive
- Brian is concerned about overcomplicating v1
One possibility for v1:
- TimedItem's have a timeSource property - points to a TimeSource
- When a TimedItem is a child of a par/seq group, the timeSource property will point to that par/seq group
- If in a future version we want to allow children to have separate parents and time source we add a parentGroup property then
- Can you modify TimedItem.timeSource to re-parent? I *think* the answer might be no
> No agreement here
> Shane to write up something about Timeline -> TimeSource transformations
(Continuing discussion from last time)
- How do we handle video?
e.g. You have a seq container with a video, followed by some credits / music
If the *user* presses pause / seeks the video (using the browser controls) you probably don't want the windowing behaviour.
Need to think a bit more about how buffering works too (probably maps to a kind of pausing). Just flagging these as issues for now.
- I think taking the time window approach depends on us being able to work out an API for representing it that feels simple.
a.    We floated the idea of implementation on webkit-dev and received some   push-back. Notably, some thought that name shortening was "unwebby".    Should we revert Anim → Animation, Func → Function? Or do we have   "webby" examples of name shortening we can point to?
Brian: I sympathise with this criticism.
  Proposed longification:
  Anim → Animation
        To address the concern about this being too long to type I wonder if   we  can extend Element with an animate method? (a la Raphaël)
  AnimGroup → AnimationGroup
     This happens to match the naming in Core Animation
  ParAnimGroup → ParGroup?
  SeqAnimGroup → SeqGroup?
     (These 'par' and 'seq' abbreviations already have established usage   due  to SMIL and I expect an element syntax would probably use these   names.  ParallelGroup is particularly error-prone to type especially   for  non-native English speakers.)
  TimingFunc → TimingFunction (you don't type this as often except when you access anim.timingFunction)
  AnimFunc → AnimationFunction (see below)
2012-11-29[Brian]:  Made the above changes but I still want to get feedback about extending Element.
Basically, it would let you do this:
  elem.animate({ opacity: '0%' }, 1).onend =
     function() { elem.parentNode.removeChild(elem); };
> Agreed, we'll put it in for now
The other remaining renaming is that I'm not really happy with KeyframesAnimationFunction. How are these:
    AnimationFunction -> AnimationAction
    KeyframeAnimationFunction -> KeyframeAction
    GroupAnimationFunction -> GroupAction
    PathAnimationFunction -> PathAction
    CustomAnimationFunction -> CustomAction
    AnimationFunction -> AnimationEffect
    KeyframeAnimationFunction -> KeyframeEffect
    GroupAnimationFunction -> GroupEffect
    PathAnimationFunction -> PathEffect
    CustomAnimationFunction -> CustomEffect
    AnimationFunction -> AnimationEffect
    KeyframeAnimationFunction -> KeyframeAnimationEffect
    GroupAnimationFunction -> GroupAnimationEffect
    PathAnimationFunction -> PathAnimationEffect
    CustomAnimationFunction -> CustomAnimationEffect
I'm leaning towards (c).
> Agreed to go with (c) for now.
Shane:   One major piece  of feedback in general is that the spec looks huge.  It  is, but the  implementation size is small. The polyfill will help  here,  and a primer  might too. One of our engineers is interested in  maybe  writing a primer.  Good idea?
> If one of us is bored we'll do it
b. 6.13.2. point 3 really needs some explanatory text.
> Steve to email Brian/Shane with corrected code for point three of calculating the unscaled iteration time
c.    does iterationStart = 0.5 & iterationCount = 2 cause (iteration +    timeFraction) to start at 0.5 and sweep to 2.5? If so, why is iterationStart capped to iterationCount?
Shane:  I think we all accept that iterationCount should actually match the  count of iterations, so I think it's OK to remove the requirement that  iterationStart is capped to iterationCount. Should we remove the  requirement that iterationStart > 0 too?
Brian:  Good question. I'm not sure. I've a feeling we generally try not to  have negative times but I'm not quite sure why. How would an accumulate  animation work in negative time?
> Yes, it should sweep from 0.5 to 2.5. Yes we should remove the cap of iterationCount on iterationStart. No we shouldn't let it go below 0 (accumulate acts weirdly).
Is there a use case for iterationStart > 1?
> For now let iterationStart be limited to >= 0. [0, ∞)
d. what should happen if timing parameters are changed after an animation is finished?
case A
var a = Anim(..., 2)
// @ 3 seconds
a.timing.duration = 4
case B
var a = Anim(..., 2)
// @ 5 seconds
a.timing.duration = 4
case C
var a = Anim(..., 2)
// @ 3 seconds
a.timing.iterationCount = 2
Brian: We need to talk about this. It relates to having a stateless timing model.
> We agree that stuff should come "back into scope" if the duration or iterationCount is changed.
e.    How about a root timeline with global time that underlies the  document   timelines? This would enable global-clock-synchronized  animations  (e.g.  clock-tick animations and the like) at very little  additional  complexity  cost.
Brian: Sounds attractive for syncing animations with event timestamps.
> Defer until we discuss some of the above stuff in [1-3]
f. Why do we have startDelay but not between-iteration-delay or endDelay? Triggers partly address this.
Brian: I think we discussed this and decided to defer it?
> Yes. Defer until after v1.
g. Should we expose reversing state? Should it be reversed / locallyReversed?
Brian:  I think this comes up somewhere else. I'd like to not have a special  reversing flag since otherwise there are three places to check to  determine if an animation is going backwards or not--playbackRate,  direction, and reversed.
> Agreed we want to implement reversing in terms of playbackRate (and fillMode) so we don't have three independent properties that control direction
> Defer adding reversed property (getter to query direction) until we see some use cases
h. Steve: Need to confirm desired behaviour for default animation start times within parent groups.
Brian going off track talking about autoplay behaviour...
 - Need to consider if we can align better with HTMLMediaElement's autoplay behaviour
 - May be surprising that simply creating an Animation object kick starts it. A number of people have expressed surprise at this.
   - Seems to be agreement that 'new Animation' kick-starts an animation. Not sure exactly what state a new Animation should be in, but it probably shouldn't start until you call play(). If you want to create and start a simple animation then the proposed Element.animate method will be the way to go there.
The issue here is when you have an Animation that DOESN'T have a start time and you add it to a par group
 - currently it uses the current iteration time of the parent as the start time
 - that's counter-intuitive when you're repeating since on the next iteration the animation starts part-way through
 - it also might be counter-intuitive when reversing since you won't see the animation until the prev iteration (although this may be unavoidable)
> Steve to think about alternative behaviour
One note to bear in mind is that the current behaviour was decided at a point where we expected Animations by default would be added to a document-level par group and this may no longer be the case.