[web-animations] Web Animations minutes, 10 Feb 2015

Web Animations minutes, 10 Feb 2015

Present: Doug, Shane, Brian
Archived etherpad: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.30455

Agenda:
1. Renaming and simplification
2. Reworking current / in play / relationship between nodes and players
3. Renaming to iterationCount, timingFunction, and fillMode
4. Promises again
5. Events
6. Additional input for keyframe effects?
7. Returning lists
8. Animation end behavior


(Following is a summary of a very short ad-hoc meeting. Many topics 
raised, not many conclusions reached.)

1. RENAMING AND SIMPLIFICATION
==============================

See: https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0042.html

At a glance:
* Remove AnimationEffect and roll into Animation
* Rename Player -> Animation
* Rename Animation -> AnimationEffect (= KeyframeEffect, GroupEffect, 
SequenceEffect)

Concerns:
Does this mean we can't share effects anymore? Specifically: sets of 
keyframes. Concern about the cost of parsing keyframes over and over 
again to clone. Perhaps we could make KeyframeEffect point to a 
KeyframeList object that could be shared?

 > Bring this up in FXTF tomorrow


2. REWORKING CURRENT / IN PLAY / RELATIONSHIP BETWEEN NODES AND PLAYERS
=======================================================================
(Brian)

I'm trying to straighten out the relationships in the model somewhat.

I think the relationship between players and nodes (and likewise groups 
and children) should be, as far as possible, one way. That is nodes are 
basically dumb things that get an input time from something (a parent 
group, a player, potentially even script, it doesn't matter).

The only time I think nodes need to know about their players/parents is 
when we do tree surgery and need to preserve the invariant that nodes 
aren't bound to multiple players/groups. Nodes themselves should never 
have to reach up to their parents.

I looked at doing this in the spec and the only places the association 
between nodes and players is referenced is:
   * to define "inherited time" -- we should just rephrase this in terms 
of "input time" and make it sound more like push instead of pull
   * the "in play" definition which is used in the following ways:
      * to define non-normatively when fill modes apply, which could be 
fixed I'm pretty sure
      * to define "current" which we only use for getAnimationPlayers() 
which needs to be reworked anyway

That last point is the sticking point: what should the behaviour for 
getAnimationPlayers() be?

Do we actually want to return all animations? We probably want, for 
example, cancelled animations to be skipped. Could we just say all 
animations that aren't idle, and then say UAs will do their own 
filtering of results, beginning with animations that have finished that 
are not in effect? I'd actually prefer if it was more aggressive and 
never returned animations that have finished and are not in effect. On 
mobile, at least, it seems we'd like to drop those objects as soon as 
possible.

It would be pretty neat to get rid of the "current" and "in play" states 
altogether if possible and just leave "in effect" (which is simply, is 
the active time null or not?)

 > To discuss later since we clearly weren't going to reach a resolution 
on this today in the time available.


3. RENAMING TO iterationCount, timingFunction, AND fillMode
===========================================================

 > Take to group


4. PROMISES AGAIN
=================

Sub-topics:
- Have a single promise or split them up?
- Have start() which returns a promise?

 > Needs further discussion: e.g. if we add start shouldn't it parallel 
finish? What about resume()? unpause()?


5. EVENTS
=========

Events are useful when re-using players because it saves you having to 
rebind to the (new) finished promise each time you restart the player. 
Brian still not sure if they are useful *enough*, but agrees they are 
useful. Shane has opposite opinion (of course) :-D

 > Take to the FXTF


6. ADDITIONAL INPUT FOR KEYFRAME EFFECTS?
=========================================

Keyframes are always lists now. Proposal to add a dictionary input where 
properties are the keys, and values are always lists.

Currently you can do:

   elem.animate({ left: '100px' }, 3000);

To add a second frame you do:

   elem.animate([ { left: '100px' }, { left: '200px' } ], 3000);

The proposal is to *also* allow:

   elem.animate({ left: [ '100px', '200px' ] }, 3000);

The main difference to previous similar proposals is that you *can't* 
also specify positional offsets / composite modes etc. using this 
syntax. For that you need the list-of-frames syntax.

 > Shane to create a pull request. This should be gated on 
implementation experience (that should called out in the PR).


7. RETURNING LISTS
==================

Re: getAnimationPlayers() which returns a sequence of AnimationPlayer 
objects we received feedback that this was "Java-ish". We want to check 
that this is the current best practice for returning lists. We also want 
to know with regards to setFrames()/getFrames().

 > Brian to talk to heycam about what best practice is regarding 
returning lists.


8. ANIMATION END BEHAVIOR
=========================

There seems to be confusion about the consequences of making a 
forwards-filling animation. Authors find it confusing that a 
forwards-filling animation clobbers any subsequence changes to the 
specified value of properties with animations. Not sure how to fix this.

 > Shane to raise this topic at FXTF


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

Received on Tuesday, 10 February 2015 05:29:30 UTC