[web-animations] Web Animations minutes, 27 Feb 2014

Web Animations minutes, 27 Feb 2014

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

Agenda:

1. Status update
2. Mutability of the target member of Animations
3. Naming groups and everything
4. Addition by appending
5. Accumulate vs. composite


1. STATUS UPDATE
================

Brian:
- Merged major reworking of animation model into ED, please review

Doug:
- Implementing groups. Will send some minor spec fixes.

Shane:
- Implementation work


2. MUTABILITY OF THE TARGET MEMBER OF ANIMATIONS
================================================
(Doug)

Doug provides a use case: tool that allows animations to be edited. Want 
to be able to change target in tool without recreating animation. Also 
want to be able to play animations on clones of target to show partial 
effects.

Brian: a bit of extra implementation work but doesn't seem too hard. 
Let's make it mutable until we work out why we originally decided not to :)

 > Brian to update the spec


3. NAMING GROUPS AND EVERYTHING
===============================
(Brian)

One of the four remaining changes to make before the next WD is naming 
of timing groups. We want to get this right soon if possible to avoid 
generating a lot of tutorial/demo content with names that change.

Previously we were talking about TimedChain and TimedGroup (I think). 
Brian didn't like the "Timed" part since he thinks "Timing" or "Time" 
are easier to remember, particularly for non-native speakers of English. 
Also, he thinks it's difficult to remember if it's "TimedGroup", 
"TimingGroup" or "TimeGroup".

Current proposal: stop being so religious about the distinction between 
"timing" and "animation" (at least from a naming point of view). We're 
an "animation" API after all, let's use "animation" more freely.

This leads to: AnimationGroup and AnimationSequence.
(From memory this happens to line up with an Apple API somewhere?)

Doug: But the groups would contain TimedItems? Seems OK, never really 
need to type 'TimedItem'
(Brian: We could rename it to AnimationItem if needed later)

Doug: Do we need to keep TimingGroup? Or could AnimationSequence extend 
AnimationGroup?

Brian: What does Liskov substitution principle suggest? Maybe it's ok?

Doug: The only difference is the start time of children.

Shane: Since you can't set the start time from the API I think it's fine.

Also, I (Brian) think we should rename Player to AnimationPlayer.

Brian: I'm warming to the idea of Element.animate returning a player. 
Part of my resistance is the naming, 'animate' -> 'player'. If animate 
returned an AnimationPlayer that somehow seems more natural. Also, 
'Player' alone is quite generic.

Shane: Would it be animation.player or animation.animationPlayer?
Brian: I think it should still be animation.player
Shane: +1

Doug: What about Timeline? Should it be called AnimationTimeline? Again, 
not something that needs to be typed very often.

Shane: I like AnimationTimeline
Doug: document.timeline? Maybe keep this. In general it seems we prefer 
the shorter names for attributes.
Shane: +1

Brian: With regards to the return value of Element.animate (which 
renaming Player->AnimationPlayer might facilitate), making animate 
return a player has the advantage that you can do:

   elem.animate(...).pause();

as opposed to:

   elem.animate(...).player.pause();

It also *might* pave the way for a more simple approach to events (e.g. 
defining events on players only).

It would, however, probably require defining the ctor for groups such 
that they can take a sequence of (TimedItem or AnimationPlayer) so that 
you could still do:

   new AnimationGroup([ elemA.animate(...), elemB.animate(...) ])

Assuming we adopt this naming, we might want to change

   Element.getCurrentPlayers (and likewise Document.getCurrentPlayers)

to either of the following:

   Element.getCurrentAnimationPlayers
   Element.getAnimationPlayers

(My preference is for the latter and just say in the documentation that 
it only returns the players that are current)

Or even keep current naming? Element.getCurrentPlayers?

Shane: But Animation.player returns an AnimationPlayer, and 
Document.timeline returns an AnimationTimeline so I think it is ok to 
keep getCurrentPlayers.

krit: If we are naming other properties Animation*, we should keep the 
name in here as well.

Doug: There's a difference between interface names and property names.

Brian: For properties within the animation API we don't repeat the 
'animation' part

krit: But Element.get... is on Element. Not within the animation API.

Brian: Good point.

Doug: If this were to change to get..AnimationPlayers, it suggests to me 
that timeline.play would be timeline.playAnimation.

Shane: nooooooo

Doug: Perhaps it doesn't suggest this, if we consider the animation api 
separately from Element, Document etc.

Brian: document.animationTimeline is a lot to type

krit: agreed. using 'animation' all the time is anoying.

(Further discussion about Element.getCurrentPlayers vs 
Element.getAnimationPlayers)

When we come to add MediaRefs (or whatever we call them), all this talk 
of animation might seem a little odd, but I think people will quickly 
work it out: "it's an animation API but it happens to be useful for 
sequencing in general". I think the idea of having most interface names 
begin with "Animation" adds a degree of coherency and reduces the 
likelihood of clashes with other APIs.

Proposal: Change naming now (AnimationGroup, AnimationSequence, 
AnimationPlayer) but leave any changes to the return value of 
elem.animate() until a subsequent WD.

Summary:
--------------
ParGroup -> AnimationGroup
SeqGroup -> AnimationSequence : AnimationGroup
TimingGroup -> /dev/null
Player -> AnimationPlayer
Timeline -> AnimationTimeline

Don't change
-----------------
document.timeline
animation.player
element.getCurrentPlayers
document.getCurrentPlayers

 > Brian to work into spec before the next WD


4. ADDITION BY APPENDING
========================
(Brian)

For transforms, we define addition as appending to a list. That's 
problematic for accumulation because if you have an animation that 
repeats indefinitely that list will just get longer and longer.

I came across the same situation in reviewing: 
http://dev.w3.org/fxtf/filters/#interpolation-of-filters. There was a 
suggestion that filters add by appending to a list but that introduces 
the same issue.

Another consideration is whether accumulation should actually be a 
different *kind* of addition, i.e. produces a different visual result. 
That is what happened with SVG's animateTransform 
(http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/ 
) Sometimes that might actually make sense. For example, does 'blur(2) 
blur(2)' produce the same result as 'blur(4)'? Not, but, for 
accumulation you probably want 'blur(4)' right?

Proposal: Have two types of addition: one for adding independent 
animations one for accumulating animations. For many animation types 
(e.g. lengths) they will be identical, but for things like lists they 
will differ, e.g. appending to the list vs component-based addition.

Shane: I like the naming 'accumulation' and 'addition'
What happens if you accumulate things with different argument lengths or 
types?
e.g. translate(100px) ACCUMULATE rotate(45deg)
or
translate(100px) ACCUMULATE translate(50px) rotate(20deg)

I think
(1) this is a useful primitive
(2) we should expose this as a composite operator
(3) this solves the GSAP use case

BUT we need to solve the above problem
one proposal: accumulate until you can't, then fall back to add
e.g. TSRRT accumulate TSTRT
you can accumulate the TS, but not R with T. So add RRT to TRT, to give 
RRTTRT
which gives:
TSRRTTRT

Brian: We should look at how to map SVG into this new idea, and look at 
the API in general

 > Shane to do this.


5. ACCUMULATE VS. COMPOSITE
===========================
(Doug)

One is on AnimationEffect, one is duplicated amongst AnimationEffect 
subclasses. Should we be consistent?

Brian: This isn't an accident. Accumulation is fundamental to the model 
of an effect. On the other hand, the application of composite is 
specific to each effect - for a while there was talk about composite 
having different values on different effects.

So for example, KeyframeEffect's composite is a fallback or default 
value. OTOH, MotionPathEffect doesn't have per-segment composite 
operations, so the composite here is just ~the~ value.

Brian: On the other hand, that seems more like a model concern. Maybe 
the interface should be different?

 > Brian to move composite to the base class


Next meeting: Shane, Doug, Mike and Brian to catch up in Tokyo sometime 
between 12~14 March. Will touch base with Dirk at an appropriate time 
during that period.

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

Received on Friday, 28 February 2014 01:05:25 UTC