[web-anim] Web animations minutes, 18 / 19 April 2013

Web animations minutes, 18 / 19 April 2013

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

Agenda:
1. Status update
2. Keyframes representation
3. Extending timing functions

Meme of the week: http://imgur.com/QfX9eXo


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

Brian: Timing events (normative parts are done, non-normative algorithm 
in progress)
Shane: Getting ready for implementation in Blink. Some more test 
infrastructure work.


2. KEYFRAMES REPRESENTATION
============================

Issue: Per-property, Per-frame, Both?

Brian leans towards per-frame:
  - CSS precedent
  - it's called keyframes

Shane: there's actually two separate issues - input and output.
  - The CSS issue is about input, the naming is probably both

Shane: if we allow per-property on input then we should require 
per-property on output.

Brian: what if it's fundamentally per-frame but we allow you to provide 
an array of values for a single property only? That would avoid the 
issues regarding precision used when lining up keyframes from parallel 
arrays.

Shane:
Are there potentially things which are per-property but which apply to a 
set of offsets?
   - (per-property) set/add animation stacking?
   - per-property timing functions?

Are there potentially things which are per-offset but which apply to a 
set of properties?
   - (per-frame) timing functions

Consider the following CSS example:

@keyframes foo {
     0% {
         top: 100px;
         left: 20px;
         color: red;
         animation-timing-function: ease-in;
     }
     20% {
         top: 200px;
     }
     80% {
         left: 100px;
         color: green;
         animation-timing-function: ease-out;
     }
     100% {
         color: white;
     }
}

Representing this per-property:

   new Animation(target, {
         top: ["100px", {offset: 0.2, value: "200px"}],
         left: ["20px", {offset: 0.8, value: "100px"}],
         color: ["red", {offset: 0.8, value: "green"}, "white"]
   }, {timingFunction: "ease-in 0.2 0.2, linear 0.8 0.8, ease-out"});

Emulating this on a per-property using a ParGroup where the key frame 
effects are per-offset:

   new ParGroup([
     new Animation(target, {0: {top: "100px"}, 0.2: {top: "200px"}}, 2),
     new Animation(target, {0: {left: "20px"}, 0.8: {left: "100px"}]}, 2),
     new Animation(target, {0: {color: "red"}, 0.8: {color: "green"}, 1 
{color: "white"}]}, 2)
   ], {timingFunction: "ease-in 0.2 0.2, linear 0.8 0.8, ease-out"});

It's probably not possible to have floats as properties but you could 
achieve this sort of arrangement in other ways, e.g.

   function animation(target, property, list, timing) {
     var keyframes = list.map(function(a) { var r = {offset: a[0]}; 
r[property] = a[1]; return r; }});
     return new Animation(target, keyframes, timing);
   }

   new ParGroup([
     animation(target, "top", [[0, "100px"], [0.2, "200px"]], 2),
     animation(target, "left", [[0, "20px"], [0.8, "100px"]], 2),
     animation(target, "color", [[0, "red"], [0.8, "green"], [1, 
"white"]], 2)
     ], {timingFunction: "[ease-in 0.2 0.2, linear 0.8 0.8, ease-out]"});

If we only allowed one target + property per animation this might get 
simpler still.

What happens to element.animate?
  - This short-cut would only support the frame-based approach. For a 
per-property approach you'd have to switch to full API.

With regards to per-property vs per-frame, Brian is concerned about the 
API straying too far from the CSS syntax since he expects most users of 
the API will be coming from that background. If the two differ too much 
then there is a strain on the author to continuously translate between 
the two.

Shane is concerned about providing interfaces that don't map well to 
what people want to do. If keyframes sets that have keyframes with 
missing properties are common, then the CSS syntax is not a good mapping 
for the kinds of animations that people are writing. However, 
conditional on being able to chain timing functions together, the syntax 
above addresses this concern fairly well.

So we have established that there are two ways of thinking about these 
things: per-frame and per-property. We don't really know which is 
better/more common. However, we *could* cover both by:

a) making KeyframeAnimations be frame-based
b) using par groups for a property-based approach

Steve points out that without allowing chaining of timing functions, 
doing per-frame timing is horrendous regardless of the syntax we use.

Some discussion about whether we still want to allow a timing function 
on a keyframe. There is some unease about mixing timing and animation 
like this. At the same time, we don't want to stray too far from 
CSS--but actually what we've currently spec'ed doesn't match CSS in this 
area (we apply the timing function on the timed item across the whole 
iteration--whereas CSS does it per keyframe).

 > For now we will leave key frame animation effects as being per-frame 
based largely on the need to align with CSS.

 > We also recognise that chaining of timing functions seems more useful 
and worth pursuing

 > There seems to be a desire to NOT have timing functions per-frame but 
to make the timing functions belong squarely in the timing model. Brian 
wants to think about this mapping a bit more since it diverges from CSS.


3. EXTENDING TIMING FUNCTIONS
=============================

Steve suspects that having chained timing functions might introduce some 
redundancy in that the same effect can be generated either by moving the 
chain points around or by changing the effect parameters. He doesn't 
think that's necessarily a bad thing but wants to think about it a bit more.

Issue from last time: Extend cubics only? Allow patching together 
functions? Do nothing?

Regarding the chaining of timing functions, Brian is concerned with 
having the timing functions with two numbers after it:
(1) it's a new concept - 'rendering' the timing function into a window.
(2) the numbers aren't self-explanatory from a readability point of 
view. Could we make it more obvious what they are or reduce to a single 
number?

We can definitely define no-number and one-number variants. It's 
important to note that general bouncing and springing behaviours _can't_ 
be defined with these variants.

 > Sydney team to flesh this out a little more - look at Steve's 
concern, improve the syntax, try and remove the extra concept if possible.

Something to keep in mind, this is somewhat similar to the approach SVG 
takes with keySplines, keyTimes etc.


Next meeting: TBD @ https://etherpad.mozilla.org/VkZ9CrBNhO

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

Received on Friday, 19 April 2013 03:07:03 UTC