Server Notice:

hide

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

 
Meeting 35:
 
Web animations minutes, 10 / 11 December 2012
 
Present: Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles
 
Agenda:
 
1. Status update
2. Time sources
3. Groups and time windows
4. Small fry
 
1. STATUS UPDATE
================
 
Brian:
- Finished changes to KeyframeAnimation interfaces
Steve:
- Still working on adding TimeSources to polyfill, hung up on numerous bugs in existing logic.
Shane:
- Implemented color handling in polyfill, thinking about Timing
Doug:
- Implemented PathAnimationFunction in polyfill using SVGPathElement#getPointAtLength
 
2. TIME SOURCES
===============
(Brian)
 
- 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
 
3. GROUPS AND TIME WINDOWS
===========================
(Continuing discussion from last time)
 
Brian:
- 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.
 
Brian:
- I think taking the time window approach depends on us being able to work out an API for representing it that feels simple.
 
4. SMALL FRY
============
(Shane)
 
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:
 
(a)
    AnimationFunction -> AnimationAction
    KeyframeAnimationFunction -> KeyframeAction
    GroupAnimationFunction -> GroupAction
    PathAnimationFunction -> PathAction
    CustomAnimationFunction -> CustomAction
    Animation.animationFunction->action
(b)
    AnimationFunction -> AnimationEffect
    KeyframeAnimationFunction -> KeyframeEffect
    GroupAnimationFunction -> GroupEffect
    PathAnimationFunction -> PathEffect
    CustomAnimationFunction -> CustomEffect
    Animation.animationFunction->effect
(c)
    AnimationFunction -> AnimationEffect
    KeyframeAnimationFunction -> KeyframeAnimationEffect
    GroupAnimationFunction -> GroupAnimationEffect
    PathAnimationFunction -> PathAnimationEffect
    CustomAnimationFunction -> CustomAnimationEffect
    Animation.animationFunction->effect
    
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
 
etc...
 
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.