Server Notice:

hide

Public Pad Latest text of pad i6bC4S4gzA Saved April 4, 2013

 
Web animations minutes, 4 / 5 April 2013
 
Present: Doug, Shane, Steve, Brian
 
Agenda:
1. Status update
2. Keyframe effect animations / handling missing key frames
3. Keyframes specifying multiple properties
4. Shrinking the API surface area
5. F2F dates
 
1. STATUS UPDATE
===============
 
Brian:
- Still reworking the spec, up to events
 
Shane:
- Matrix interpolation in polyfill
 
Steve
- Tweaking media integration in polyfill
 
2. KEYFRAME EFFECT ANIMATIONS / HANDLING MISSING KEY FRAMES
========================================================
 
Proposal:
 
In brief:
Full form of a keyframe dictionary is:
{offset: <number|"auto">, value: <CSS String>, composite: <"add"|"set"|"auto">}
 
However:
* composite can be left out, and defaults to "auto"
* offset can be left out, and defaults to "auto"
* keyframes without explicit offset or composite values can be specified as just the value string
 
keyframe lists are lists of keyframe dictionary values (or strings). e.g.
 
["50px", {offset: 0.2, value: "25px", composite: "add", "100px"]
 
keyframes dictionaries map properties to keyframe lists, and also allow a global composite to be specified, e.g.
 
{left: ["50px", {offset: 0.2, value: "25px", composite: "add", "100px"], composite: "set"}
 
The global composite defaults to "set".
 
"auto" composite implies that the global composite value is used.
"auto" offset implies that the keyframe (along with any "auto" offset contiguous keyframes) will be distributed evenly in the available space. As an exception, a single keyframe with "auto" offset will always be placed at an offset of 1.
 
QUESTION: Should we just use null for "auto" offset?
 
> Brian to follow up with Cameron about what's better here
 
See document for details of the compositing algorithm given a keyframe list, an underlying value, and an interpolation fraction.
 
> Brian to work this into spec
 
What about Path animation effects?
 
For now add a composite operation to path animation effects.
 
This 'global' composite operation parameter will be specified on each sub-type of animation effect--not on the superclass AnimationEffect--since there may be animation effects we add in the future for which the composite operation doesn't make sense.
 
Steve has a concern that having a 'global' composite operation on keyframes may cause problems in the future. We'll think about this for the next few days to see if we can come up with any concrete examples of problems. In the absence of any we'll stick with the 'global' option.
 
3. KEYFRAMES SPECIFYING MULTIPLE PROPERTIES
===========================================
(Brian)
 
We currently have a model with a 1-to-1 correspondance between an animation effect and a target property. Reasons why:
 
*  Makes describing the compositing easier (but this is a bit of a  non-issue since what you're really compositing is animation values, not  the effects)
  -- This means you don't end up with part of an animation effect being applied and part not being applied
  
*  We want to avoid an architectural pattern where these animation effects  get increasingly blobbish--i.e. if we allow a key frame animation  effect to target multiple properties how long will it be before we start  getting requests to add a start delay per property to animation  effects?
  -- Looking at how CSS is used I'm not sure how big a deal this is?
 
I'm  not sure that either of those are major concerns and I think authors  will find it both surprising and frustrating that you can't have  multiple properties in the API even though you can in CSS.
 
Shane: +1. In fact the polyfill transparently allows the specification of multiple values. At the moment it silently inserts a GroupAnimationEffect, but I would prefer KeyframeAnimationEffect to deal with multiple properties directly.
 
I think we should revisit this. I'll have to rewrite the animations stuff significantly but I think it's worth it.
 
Update:  Either this, or the ability to have multiple animation effects per  Animation is necessary to support Animation ctors of the form:
  new Animation(elem, { left: '10px'; right: '10px' }, 5);
 
Shane: (historical note) that is supported by the GroupAnimationEffect - i.e. we don't _need_ to change. I still think we should.
 
And if we're to support:
  AnimationEffect.createFromString({ left: '10px'; right: '10px' })
It has to be this.
 
We all agree. KeyframeAnimationEffects will henceforth be able to target multiple properties.
 
4. SHRINKING THE API SURFACE AREA
================================
(Brian)
 
I wonder if we can remove the animation effect interfaces like KeyframeAnimationEffect / PathAnimationEffect.
 
Just make AnimationEffect an opaque class with a ctor. So you can still *make* new animation effects but passing in the appropriate property bags but you can't modify / inspect them?
 
Shane: maybe a method to extract the property bags too so you can extract-modify-create as a poor-man's update?
 
Or, alternatively:
 
dictionary KeyframeParams {
    sequence<KeyframeValueParams> values;
    double                            offset = 1;
    DOMString?                        timingFunction = null;
};
 
dictionary KeyframeValueParams {
    DOMString          property;
    DOMString          value; // Make this any?
    CompositeOperation composite = "set";
};
 
typedef sequence<KeyframeParams> Keyframes;
 
[Constructor (Keyframes frames,
              optional AccumulateOperation accumulate = "none")]
interface KeyframeAnimationEffect : AnimationEffect {
    Keyframes getFrames();
    void setFrames(Keyframes frames);
};
 
* setFrames is not strictly necessary -- just create a new KeyframeAnimationEffect to set them.
 
In the ctor (and setFrames if it exists) still provide special wording for ECMAScript to support:
 
   { left: '100px' }
   { left: '100px', top: '20px' }
   { left: ['100px', '200px'] }
   { left: ['100px', '200px'], composite: 'add' }
   { left: ['100px', '50px', '200px'], opacity: ['0', '1', '0'] }
   { left: ['100px', '50px', '200px'], opacity: ['0', {offset: 0.2, value: '1'}, '0'] }
 
But when you call getFrames you always get back the normalized version,
 
e.g.
 
  { left: ['100px', '200px'] }
  
expands to:
 
   [
     {
       offset: 0,
       values: [ { property: 'left',
                   value: '100px',
                   composite: 'set' } ]
     },
     {
       offset: 1,
       values: [ { property: 'left',
                   value: '200px',
                   composite: 'set' } ]
     }
  ]
  
Notes:
* This proposal is doing three things at once
 - refactoring the keyframes interfaces to drop all the nested interfaces and just use dictionaries
 - adding the ability to target multiple properties per keyframe
 - adding the per-value composite operation
So, it makes comparison a little difficult. Sorry about that.
  
Analysis:
* It's a bit more clumsy that dealing with real interfaces
* Lets us drop the KeyframeList interface (which is reasonably large but fairly straightforward)
* Lets us drop the Keyframe interface
* We already have KeyframeDictionary (= KeyframeParams in this case)
* KeyframeValueParams here is new but that's because this handles multiple target properties per key frame so we need to add this anyway
* Overall the surface area is smaller but a reasonably noticeable amount
* We can still add the Keyframes interfaces in a future version once we have a better idea of the needs
 
Notes: as an internal representation, sorting by property is probably easier (not sorting on a continuous value, no need to construct missing values). This doesn't need to impact the specification.
 
Lots of discussion over whether per-property or per-offset sorting is 'better' for animators. We concluded there are arguments in both directions. We could potentially measure the sparsness of properties in @keyframes rules as an indication of how suitable sorting-by-offset is.
 
Steve is somewhat reluctant to support both representations, mainly from the perspective of reducing the specification surface area.
 
It's possible that there might be a nice hybrid representation that allows nesting of per-property and per-offset sorting sections within each other. Shane is going to have a think about this.
 
This might be a problem: { left: ["0px", "50px", "200px", "300px"], opacity: [{offset: 0.33, value: "0"}] }. Discussed providing a fixed offset min-delta to avoid.
 
5. F2F DATES
==========
 
When to meet in Tokyo?
27-31 May
 
Meeting time from here on: same time in Sydney
9am Tokyo / 10am Sydney / 5pm MTV