[web-anim] Web animations minutes, 11 / 12 April 2013

Web animations minutes, 11 / 12 April 2013

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

Agenda:
1. Status update
2. Extended timing functions
3. Keyframes representation
4. Representing timing parameters


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

Brian: Struggling with events
Steve: blink
Shane:
  - matrix interpolation in polyfill
  - moving tests over to new test framework
  - extended timing functions
  - some blink work


2. EXTENDED TIMING FUNCTIONS
============================

Shane: 
https://docs.google.com/document/d/1KjfY7ok3bmltAWOna7p0RzHnj49SRZVAQZhjO0wjS9s/edit#heading=h.v9ginwuoznmr

Discussion of extending cubic-bezier vs. chaining timing functions vs. 
NURBS.

We have two alternatives we are considering at the moment:

A) Extend cubic-bezier to accept more numbers, basically instead of just 
4 numbers you could have: 4,10,16,22... etc.
These just define the intermediate control points of a chain of cubic 
bezier segments whose start and end points are (0,0) and (1,1) respectively.

Analysis:
* Hard to read/tweak once you get past about one segment--pretty much 
impossible
* Changes to parsing/spec is simply the number of points allowed

B) Allow timing functions to be chained together:
e.g. "linear 0.2 0.2, ease 0.5 0.4, cubic-bezier(1, 0, 0, 1) 0.8 0.7, 
ease-in 1 1"
The two numbers following each function specify the "window" into which 
the function is scaled. So the endpoints of the 'linear' function are 
0,0->0.2,0.2, then 'ease' goes from 0.2,0.2->0.5,0.4 etc.

Analysis:
* Much easier to tweak, hand-author
* Allows combining discrete functions with smooth ones--although we may 
or may not allow this
* Requires more characters for a curve represented by many cubic bezier 
segments

(A) and (B) are not mutually exclusive. Question is which do we do? Or 
which do we do first?

Also, in either case we might later add syntax for automatically 
reflecting control points, e.g. smooth-bezier() or cubic-bezier(smooth, 
x, y) etc. similar to SVG's 'S' command.

 > Currently undecided. Brian leans towards (A) (with shortcuts added in 
a later level) since it seems like a smaller change; Shane and Steve 
lean towards (B) because it is more readable/hand-authorable.


3. KEYFRAMES REPRESENTATION
===========================

There are three pending changes:
- Allow per-value composite modes
- Allow multiple target properties per key frames animation effect
- Removing interfaces and replacing with dictionaries

These three are blocked on working out how to represent the key frames:
(a) by-frame only,
(b) by-property only,
(c) by-frame with shortcuts to allow constructing them with property 
value arrays
(d) by-property with shortcuts to allow constructing them by frame

The by-frame approach has the advantage of matching what CSS does. It 
also *may* be more intuitive for animators--we're not sure.

The by-property approach has the advantage of being simpler to 
construct. It also matches SVG's behavior more closely. It also avoids 
the issue that arises when you have automatically spaced keyframes mixed 
with fixed offsets and whether or not two values appear in the keyframe 
depends on the precision with which the offsets are calculated/specified.

 > Still waiting on further investigation.


4. REPRESENTING TIMING PARAMETERS
==================================

Where are we up to with this?

Currently we have:

interface TimedItem : EventTarget {
    // Specified timing
    TimingDictionary getTiming ();
    TimingDictionary setTiming (TimingDictionary timing);

    // Calculated timing
    readonly attribute double              startTime;
    readonly attribute unrestricted double iterationDuration;
    readonly attribute unrestricted double activeDuration;
    readonly attribute unrestricted double endTime;
};

* Re-uses the timing dictionary to keep the API surface area small
* Has the unfortunate side-effect that:
       anim.setTiming({ iterationDuration: 3 })
   clobbers all other timing. It's possible to work around this but clumsy.


Alternative A:

Introduce Timing interface.

* Duplication of parameters: a dictionary version and an interface 
version  → increases API surface area, awkward to maintain / spec


Alternative B:

interface TimedItem : EventTarget {
    // Timing
    attribute double   startDelay;
    attribute FillMode fillMode;
    attribute Duration iterationDuration;
    attribute Duration activeDuration;
    attribute double   playbackRate;
    // ...

    // Scheduled time
    readonly attribute double              startTime;
    readonly attribute unrestricted double endTime;
};

interface Duration {
   double    sec;
   DOMString string;
}

Usage:
  var specifiedDur = anim.iterationDuration.string; // "auto"
  var computedDur = anim.iterationDuration.sec; // 5

  // Update duration to 3s
  anim.iterationDuration.sec = 3;
  // anim.iterationDuration.string -> "3s"

  // Update duration to 3s (alt.)
  anim.iterationDuration.string = "3s";
  // anim.iterationDuration.sec -> 3

  // Reset to auto
  anim.iterationDuration.string = "auto";
  // anim.iterationDuration.sec -> 5

* Some duplication of parameters between the dictionary and TimedItem
* Setting and reading duration happens in same place
* Mimicks patterns proposed for CSS Lengths and SVGLength
* Easy to extend this to support percentage measures in the future 
(which is likely for duration properties)
* Not easy to apply this pattern to other parameters in the future (e.g. 
if we want to make playbackRate accept a string we'd have to introduce 
another attribute in order to use the same pattern)


Next meeting (and from here on) will be one hour later:

Thurs Apr 18 18:00 PDT / Fri 19 Apr 11:00 AEST / Fri 19 Apr 10:00 JST @ 
https://etherpad.mozilla.org/BeNadjGK63

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

Received on Friday, 12 April 2013 02:10:26 UTC