[web-animations] Web Animations minutes, 5 / 6 Dec 2013

Web Animations minutes, 5 / 6 Dec 2013

Present: Alan, Doug, Shane, Steve, Brian
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.XgDJWjXpD2w/latest

Agenda:

1. Status updates
2. Interpolation of images
3. Player changes
4. Naming of timing groups
5. Renaming PathAnimationEffect to MotionPathEffect?
6. Factoring out paced timing as separate to easing


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

Brian:
  - Player changes (see below)
  - Presentation at html5j: 
http://brian.sol1.net/svg/2013/12/04/web-animations-html5j-2013/


2. INTERPOLATION OF IMAGES
==========================

http://dev.w3.org/fxtf/web-animations/#the--image--type The spec says to 
use CSS4 Images - 
http://dev.w3.org/csswg/css-images/#cross-fade-function - but this 
requires the intepolation fraction to be limited to [0, 1].  We should 
add that the fraction is clamped to this range before using  the CSS4 
Images algorithm.

 > Actually, we should just replace the <image> section by saying, 
"Interpolation is defined in CSS4 Images"


3. PLAYER CHANGES
=================

The spec text is not quite right. Alan has provided some excellent 
feedback and Brian will try to fix the spec ASAP.

Some discussion about whether Element.animate() should return an 
Animation or a Player? Brian still feels like Animation is right, but 
others are not sure. Use cases include:

i. Building up groups:
   new TimedGroup( [ elem.animate(...) ] );
   vs. new TimedGroup( [ elem.animate(...).source ] );, or allowing 
Players to be passed into TimedGroup lists..

ii. Adding onend listener:
   elem.animate(...).onend = ...
   vs. elem.animate(...).source.onend, or adding events to Players, or 
Object.observe()?

iii. Modifying timing
   var anim = elem.animate(...)
   anim.specified.delay = ....
vs. var anim = elem.animate(...).source; anim.specified.delay = ...

On the other hand:
elem.animate(...).pause() // build a paused animation
  vs elem.animate(...).player.pause()
elem.animate(...).currentTime = ... // CSS-style "scrubbing"
  vs elem.animate(...).player.currentTime = ...

 > Still not entirely sure what Element.animate should return. Feedback 
is welcome.

Discussed events with regard to where onend lives. If element.animate 
returns a player we should probably have onend on player as well which 
means we need to define player events.

We will return to this discussion later when we try to solve events once 
and for all.


4. NAMING OF TIMING GROUPS
==========================
(Brian)

Original thread:
http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0115.html
Follow-up threads:
http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0124.html
http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0123.html

Current proposals:

A. SyncGroup and SequenceGroup (elements: <sync> and <sequence>)
- Clear but too similar to each other?
- 'Group' naming is generative and emphasises that they are the same 
kind of thing
c.f. http://doc.qt.digia.com/qq/qq13-apis.html#theartofnaming
   "Identify groups of classes instead of finding the perfect name for 
each individual class. For example, All the Qt 4 model-aware item view 
classes are suffixed with View (QListView, QTableView, and QTreeView), 
and the corresponding item-based classes are suffixed with Widget 
instead (QListWidget, QTableWidget, and QTreeWidget)."

B. TimedGroup and TimedChain (elements: <timedgroup> and <timedchain>)
- Clear and distinctive
- Not so generative, not quite so clear that they are the same kind of thing
- What do you call them collectively: "timed groups" vs "a regular timed 
group" ?
- Should it be
   TimingGroup / TimingChain ?
   TimedGroup / TimedChain ?
   TimeGroup / TimeChain ?
   (Brian: I accidentally got this wrong in my presentation and called 
it TimingGroup/TimingChain although the original proposal was 
TimedGroup/TimedChain)

Other permutations:
* SyncGroup and ChainGroup ?
* TimedGroup and TimedSequence ?

Some concern that TimedSequence is longer than TimedChain and not 
necessarily significantly clearer. In light of that TimedGroup / 
TimedChain seems preferable.

Brian somewhat uncomfortable with "Timed" particularly in element syntax 
"timedgroup" and from a non-English speaking background point of view, 
"Time" and "Timing" are more simple/familiar.


5. RENAMING PathAnimationEffect TO MotionPathEffect?
====================================================

PathAnimationEffect sounds like it animates a path's points, not moves 
an element _along_ a path. Also, unlike KeyframeAnimationEffect, you 
actually *do* type PathAnimationEffect.

Suggested renaming:
- AnimationEffect remains the same as the common base class
- PathAnimationEffect -> MotionPathEffect (based on the common concept 
of a "motion path" as used in, e.g. Office, After Effects etc.)
- KeyframeAnimationEffect -> KeyframeEffect
- CustomEffect remains the same

Disadvantage: Naming no longer distinguishes betweens custom effects and 
animation effects (PathAnimationEffect and KeyframeAnimationEffect 
inherit from AnimationEffect and are composited according to the 
prioritisation outlined in the model but custom effects are run later). 
However, the name "custom effect" does suggest special handling.

 > The renaming sounds good.


6. FACTORING OUT PACED TIMING AS SEPARATE TO EASING
===================================================

The idea here is that pacing is a separate property applied to space out 
the animation values (be they keyframes or points on a path). Easing is 
applied *after* that.

That allows you to pace a path and then ease the entire motion whereas 
currently you can't do that.

For keyframes you'd have three modes:
* Keyframes are evenly distributed
* Keyframes are distributed so that the rate of change of a given 
property is constant (for properties where this makes sense)
* Keyframes have their positions specified explicitly

If the author specifies both "paced" and "explicit offsets" we need to 
determine the behaviour.

Lots of edge cases to consider. For example, is it useful to be able to 
pace an effect in general but specify absolutely the offset of just one 
value?

The idea that pacing should always override any offsets is 
attractive--would let you switch on paced timing globally without having 
to unset all the offsets.

What do we do when there are no keyframes with the paced property? This 
seems OK - you just get even distribution, as when any keyframes are 
missing that property.

Need to decide which property to pace on. This would be a flag set at 
the effect level. Is there a default value? The first property in the 
first keyframe?

 From an API point of view, we could change:

[Constructor (OneOrMoreKeyframes frames, optional CompositeOperation 
composite = "replace",  optional AccumulateOperation accumulate = "none")]
interface KeyframeAnimationEffect {
   ...

To:

[Constructor (OneOrMoreKeyframes frames, optional EffectOptions options)]
interface KeyframeAnimationEffect {
   ...

dictionary EffectOptions {
     CompositeOperation composite = "replace";
     AccumulateOperation accumulate = "none";
     DOMString distribute = "equal" ? // Other options being 
"paced(left)" etc. ?
}

Still some uncertainty about whether pacing should always win since in 
the above arrangement "equal" would only apply when there are no offsets 
but "paced(left)" would always apply. Needs more thought.


Next meeting: Fri 13 Dec 0:00 UTC @ https://etherpad.mozilla.org/3eVWyRLwbN
   Local time: 
http://arewemeetingyet.com/Sydney/2013-12-13/11:00/Web%20Animations

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

Received on Friday, 6 December 2013 02:29:43 UTC