[web-animations] Web Animations minutes, 12 Dec 2013

Web Animations minutes, 12 Dec 2013

Present: Dirk, Doug, Shane, Brian
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.6yJjZCJWqiM/latest

Agenda:

1. Status updates
2. Meeting time
3. Respec work?
4. CSS spec
5. Handle multiplication of zero and infinity
6. Time fraction when in before phase and backwards fill with step-start 
timing function
7. Extending the active duration
8. Make IDL more extensible so other things can be animated
9. Groups with children that have infinite iterations


1. STATUS UPDATES
=================

Brian:
   - Fixing min timing in Gecko (see 7 below)
   - Integrating lots of minor edits (e.g. 5 below)
   - Trying to fix the algorithms for players based on Alan's work
     (WIP: https://github.com/birtles/web-animations-js/tree/newPlayerAPI )


2. MEETING TIME
===============

Will try the following time slot next week and wait to see if Dean can 
possibly do 8pm Sydney time next year.

    Sydney Fri 9am
    Tokyo Fri 7am
    Leipzig Thurs 11pm
    PST Thurs 2pm
    UST Thurs 10pm

Here is the Doodle: http://doodle.com/344k9sby2gc6a6i5

i.e.
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=12&day=19&hour=22&min=0&sec=0&p1=224&p2=313&p3=248&p4=240
http://arewemeetingyet.com/UTC/2013-12-19/22:00/Web%20Animations


3. RESPEC WORK?
===============

Can anyone help migrate our changes from v1 to current trunk (v3?)


4. CSS SPEC
===========
(Doug)
Transitions are straightforward.
- Transitions run on a separate timeline which has a different zero-time.
- We probably wont expose the transition timeline to script. It doesn't 
make sense to manipulate or pause transitions.
- Transitions always composite as replace and have a priority that cause 
them to apply over CSS Animations and animations started through the API.

Animations are harder because we need to deal with per keyframe+property 
timing functions.
- Want to expose KeyframeEffect objects for @keyframes rules.
- Want to allow an Effect defined by script to be used by a CSS Animation.

CSS timing-function recap:
- In CSS, a timing-function applies from one keyframe to the next.
- But in a per-property fashon.

So given <http://jsfiddle.net/dZJ5W/>, the progression of top and left 
are actually different:
@keyframes anim {
     0% {
         top: 0px;
         left: 0px;
     }
     50% {
         top: 50px;
     }
     100% {
         top: 100px;
         left: 100px;
     }
}
animation: anim 1s ease;

This can be implemented on top of the model as defined now. In Blink we 
split such CSS Animations into multiple Animations/AnimationEffects and 
use chained easings.

But depending on how we expose CSS Animations to script we have some 
options:

1. Opaque TimedItem

This would allow implementations to use 4 now and we could revisit later.

2. Animation with an opaque Effect
3. Animation with a KeyframeEffect or CSSKeyframesEffect

This seems favourable for authors. It seems likely that one would expect 
@keyframes to map to KeyframeEffect.

This requires some changes. KeyframeEffect to specify a timing function 
per property-specific keyframe. The only timing changes take place when 
interpolating between the property-specific keyframes.

Note that the specified timing would contain a linear easing.

Sub options here:
A. Model only. Timing functions would not be visible via getFrames, 
setFrames would not allow them to be specified.
B. Add to the API. Like 'offset', there would be an 'easing' per input 
keyframe.
C. Like B, but only support 'easing' on a new CSSKeyframesEffect.

4. Group of per-property Animation+KeyframeEffect
4A. Group with per-property Animations.
4B. Group with minimal set of Animations with distinct timing.
4C. Only group per-property when timing is different, one Animation 
otherwise.


 > We prefer option 3B. If we were to add timing function on a 
per-keyframe basis then the model would be closer to CSS and would 
remove the need for timing function chains (in version 1--we can add 
them later). We think this would satisfy the needs of CSS and SVG.

 > Except for SVG's animateMotion where you can apply keySplines between 
points on the path. We'd need a way to represent that if we dropped 
timing function chains.

The proposal is to keep the 'easing' on the specified timing which 
applies across the whole effect so you could, for example, ease a whole 
animation as one. This is particularly useful for motion path animation.

 > Brian to investigate the requirements for supporting animateMotion to 
see if we can drop timing function chains in v1

We prefer option 3B on the assumption that it will allow us to drop 
timing function chains. If that is *not* the case we will consider the 
other options.


5. HANDLE MULTIPLICATION OF ZERO AND INFINITY
=============================================
(Steve)

In IEEE 745 multiplication of zero and infinity is undefined, but 
currently we don't specify what the result should be. I think the 
correct result is zero in each case.

- Calculating the active duration
   iteration duration is in [0, infinity]
   iteration count is in [0, infinity]

- Calculating the start offset
   iteration start is in [0, Infinity)
   iteration duration is in [0, infinity]

- Calculating the scaled active time
   playback rate is in (-infinity, infinity)
   active time (or active duration - active time) is in [0, Infinity]

- Calculating the transformed time
   scaled fraction is in [0, infinity)
   iteration duration is in [0, infinity]

Proposed spec patch: 
https://github.com/steveblock/web-animations-spec/commit/abcbac30271deb30635797caf02d67e19ff6fab8

Brian: I merged this: https://dvcs.w3.org/hg/FXTF/rev/e804703a152e


6. TIME FRACTION WHEN IN BEFORE PHASE AND BACKWARDS FILL WITH step-start 
TIMING FUNCTION
==============================================================
(Steve)

The spec is clear that the time fraction should be 1, but I think you'd 
expect it to be zero. It's zero for all other timing functions.

I think that you could argue either way ...
- There's an expectation that backwards fill gives you the 'from' 
keyframe value
- There's an expectation that things don't change as you transition from 
backwards to fill to active

It gets more interesting if we allow timing functions to be extrapolated 
outside the range [0, 1]. In this case, I think you have to use a value 
of zero for offsets less than zero. So I think this is an argument for 
the time fraction to be zero.

I have a patch which solves this by using negative zero for the active 
time in this case. This propagates (relatively cleanly) through the 
model until it's special-cased by the step timing function. 
https://github.com/steveblock/web-animations-spec/commit/088b1290294c5b42834ee933963de56ca0a32b72

Doug points out that an equivalent siutation arises when you have a 
negative start delay equal in magnitude to any step transition point. We 
should fix this in the same way. I think the negative zero approach 
could be extended to cover this.

Shane suggests that an alternative solution is to pass a 'negativeBias / 
positiveBias' flag to the timing function when evaluating it. This flag 
would be set based on the fill mode and direction. This might be easier 
to implement.

Brian: I'd rather not introduce negative zeros into calculation of the 
active time but rather localize this change.

Can we just say that timing functions can take an extra flag to indicate 
a time before zero? We can set this flag by testing if we are in the 
'before phase' (which is already normatively defined) and let the step 
timing function use this flag?

Shane: I'm happy with timing functions being able to know that they are 
in the 'before' phase too.
Doug: +1

7. EXTENDING THE ACTIVE DURATION
================================
(Brian)

Two questions:

a) If I extend the active duration so that it is longer than the time 
taken to do all the iterations, what should happen? Keep repeating? Or 
fill? Even more fundamentally, should we even allow extending the active 
duration?
b) SVG has a 'min' attribute that allows extending the active duration 
in which case it just uses the fill behaviour for the extra time. How 
should this be represented in the model?

Background info:

* We have an activeDuration member in the Timing dictionary that lets 
you override the calculation of the activeDuration to, e.g. clamp it. 
This was added for supporting SVG's 'end' attribute which can cause an 
animation to finish early. The idea was, "don't touch the iterations 
member, just clamp it using activeDuration".

* SVG's min attribute is very rarely used and actually this behavior is 
buggy in Firefox (to be fixed in 
https://bugzilla.mozilla.org/show_bug.cgi?id=948245 ). But it is 
probably useful in combination with groups and especially when there is 
media involved where calculating the active duration is more complex. 
I'm still unclear about the specific use cases however.

* It might seem like extending the active duration by using the fill 
behaviour is no different to just ending normally. From the animation 
model point of view this is so but from the timing model it is 
different. For example, I have an animation that runs for 10s but has 
min="15s". After 10s it will use its fill behaviour but:
   - the end event will not fire until t=15s
   - syncbase dependencies based on the animation's end time will take 
it to be t=15s
   - if it is in a sequence container, the following animation will not 
start until t=15s
   - if it has restart="whenNotActive" it will not restart until t=15s 
or later
   etc.

Some scenarios:

1) Follow SVG
a) When the active duration is extended use the fill behavior (don't 
just keep repeating).
b) Implement min by extending the active duration

2) Don't override active duration / introduce endDelay
a) Don't allow clipping/extending the active duration at all (remove it 
from Timing interface). Use the iterationCount for this. For SVG's 
end/max attributes (which require clipping) just adjust the 
iterationCount as needed.
b) Implement SVG's min behavior by adding an endDelay attribute
    - end events will require special handling to fire at the end of the 
endDelay
    - syncbase dependencies too
    - sequence containers would need to use the endDelay in calculate 
the position of subsequence children
    - restart="whenNotActive" would also need this special handling
    - presumably endDelay could be negative too (but presumably a 
negative endDelay on the last child of a sequence would not affect the 
intrinsic duration of the container--i.e. it's based on when the last 
child ends?)

Changing startDelay impacts the intrinsic duration of a container. 
Symmetry suggests that endDelay probably should too.

3) Don't change much
a) As currently, extending the activeDuration makes the animation keep 
repeating (effectively making iterationCount redundant)
b) Implement SVG's min behavior using a lot of special handling. Not 
sure how to, for example, create the space between animations in a 
sequence container. Adjust the startDelay of the next sibling? Wrap the 
animation in a group. Whatever we do it's fairly hacky.

4) Change min behavior
a) As currently, extending the activeDuration makes the animation keep 
repeating (effectively making iterationCount redundant)
b) Change the spec for how min works since it is very rarely (never?) 
used. Make it so it just extends the active duration and continues 
repeating in the extra time.

However, the facility of adding space to the end of something is 
probably generally useful. (e.g. if you want to control the staging of a 
sequence group you could set min="indefinite" on each child and then 
update it when the sequence should continue)

Shane: (2) gets my vote :)
Doug: +1

 > Go with option 2


8. MAKE IDL MORE EXTENSIBLE SO OTHER THINGS CAN BE ANIMATED
===========================================================
(Shane)

Tab pointed out that, right now, it's kinda hard to extend the set of 
objects that can be animated.  It requires coordination with the WebAnim 
spec to update the AnimationTarget typedef, and repetition of the 
animate() method in each new interface.

I'd like to propose changing our IDL from this:

typedef (Element or PseudoElementReference) AnimationTarget;

[Constructor (AnimationTarget? element,
               (AnimationEffect or CustomEffect or OneOrMoreKeyframes)? 
effect, optional (unrestricted double or TimingInput) timing)]

partial interface Element {
     Animation animate ((AnimationEffect or CustomEffect or
OneOrMoreKeyframes)? effect, optional (double or TimingInput) timing);
     ...
};

to this:

[NoInterfaceObject]
interface Animatable {
   Animation animate ((AnimationEffect or CustomEffect or
OneOrMoreKeyframes)? effect, optional (double or TimingInput) timing);
  };

Element implements Animatable;
PseudoElementReference implements Animatable;

[Constructor (Animatable? animatable, (AnimationEffect or CustomEffect
or OneOrMoreKeyframes)? effect, optional (unrestricted double or
TimingInput) timing)]

This will allow us to make more things Animatable in the future (e.g. 
canvas contexts). Animatable things would automatically be able to be 
passed into the Animation constructor, and would also have the 'animate' 
method available.

We'd need to draft something in the specification that indicates new 
implementations of Animatable need to provide descriptions of which 
Effects do what, but I think this could be pretty minimal.

Brian: Sounds good in general. Is it possible that if we were to extend 
canvas to support this, the kind of arguments we'd like to pass to 
animate are different?

Possible, but I think that we can go a long way just by extending Effect 
in a new direction.

 > Brian to try and integrate this


9. GROUPS WITH CHILDREN THAT HAVE INFINITE ITERATIONS
=====================================================

If a child has infinite iterations then none of the children ever play 
since the parent never progresses.

This comes up because groups also apply timing functions which requires 
generating a time fraction that will always be zero.

We think we can fix this by adding an extra check at this step so that 
if the iteration duration of the timed item is infinite, skip the timing 
function.


Next meeting: Thurs 19 Dec 22:00 UTC @ 
https://etherpad.mozilla.org/FK6YBfMs5Y
   Local time: 
http://arewemeetingyet.com/UTC/2013-12-19/22:00/Web%20Animations

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

Received on Thursday, 12 December 2013 23:27:24 UTC