[web-anim] Web animations minutes, 4 / 5 April 2013

Web animations minutes, 4 / 5 April 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.lfR1XxRmef2/latest
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 (section 27). Nearly done.

Shane:
- Matrix interpolation in polyfill

Steve
- Tweaking media integration in polyfill


2. KEYFRAME EFFECT ANIMATIONS / HANDLING MISSING KEY FRAMES
===========================================================

Proposal:
https://docs.google.com/document/d/13oOejOlp36U9Oc0uNUSJFUJ8ebg0g80p8O16VgxFqh8/edit

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.

Brian: I think we should revisit this. I'll have to rewrite the 
animations stuff significantly but I think it's worth it.

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.

Brian: And if we're to support:
   AnimationEffect.createFromString({ left: '10px'; right: '10px' })
It has to be this.

 > We all agree. Key frame animation effects 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?

Brian (contd.):
Or, alternatively:

dictionary KeyframeParams {
     sequence<KeyframeValueParams> values;
     (double or DOMString)         offset = "auto";
     DOMString?                    timingFunction = null;
};

dictionary KeyframeValueParams {
     DOMString          property;
     DOMString          value; // Make this any?
     CompositeOperation composite = "auto";
};

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 -- you can 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'] }

(Some discussion about the last one)

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 by 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 complexity.

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"}] }. Since we don't want to it to be 
implementation whether the keyframes at ~0.33 get merged or not. 
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


Next meeting: Thurs Apr 11 17:00 PDT / Fri 12 Apr 10:00 AEST / Fri 12 
Apr 09:00 JST @ https://etherpad.mozilla.org/KG6TnwU8a0

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

Received on Friday, 5 April 2013 01:30:44 UTC