[web-animations] Web Animations minutes, 25th / 26th July 2013

Web Animations minutes, 25th / 26th July 2013

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

Agenda:

1. Status updates
2. Phased implementation strategy
3. Revisit per-property keyframe syntax
4. Add 'computed' and 'specified' timing function distinction
5. Roadmap
6. CSS Properties, Animation and Transition insertion points, and pain
7. PFWG review comments
8. Default fill mode
9. Shorthand properties


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

Brian:
  - Renamed time drift to time lag and exposed to API
  - Incorporated the new fill mode behaviour
    (which also meant renaming the 'active' state to 'in play'; 
introducing phases and a bunch of other edits--please review)
  - Blog post introducing players: 
http://brian.sol1.net/svg/2013/07/25/players-wanted-the-pause-and-seek-game/

Doug:
  - Implemented new fill mode behavior and phases in Blink
  - Announced intent to implement JavaScript API in Blink: 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/KF3Cwr_Kcl0/BSp04-_ERYkJ

Shane:
  - responding to intent to implement thread
  - thinking about GSAP use cases and responding
  - thinking about Kevin's mail

Polyfill:
  - Getting closer to automated testing on Firefox. The tests are 
running, but failures do not gate new changes yet.
  - Support for CSS keywords
  - Correct interpolation of background-position
  - Support for animating CSS shorthand properties


2. PHASED IMPLEMENTATION STRATEGY
=================================

We talked about synchronizing the release of parts of the API. Each 
phase of API implementation could then be followed by feedback 
gathering, in order to ensure that we end up with the best possible API 
at the end.

One possible phasing breakdown:
(1) Element.animate
(2) Events + Animation constructor
(3) ParGroup / SeqGroup

There seems to be support for this idea, so we should probably consider 
it a bit further then spec something out.


2. REVISIT PER-PROPERTY KEYFRAME SYNTAX
=======================================
(Doug)

Our experience with making this change in the polyfill wasn't pleasant. 
Can haz per-property syntax back (in addition) plz?

The "chosen" syntax is per-offset:

   [{offset?: 0.2, composite?: add, (<property>: <value>)*}*]

For example:

   {left: "100px"}
   [{left: "0px"}, {left: "100px"}]
   {left: "100px", top: "120px"}
   [{left: "0px", top: "20px"}, {left: "100px", top: "120px"}]
   [{left: "0px", top: "20px"}, {top: "120px", offset: 0.7}, {left: 
"100px"}]
   [{left: "100px", top: "20px"}, {top: "120px", offset: 0.7}]
   [{left: "100px", top: "20px"}, {top: "120px", offset: 0.4}, {left: 
"50px"}, {top: "100px", offset: 0.7}]
   [{transform: 'translate(100px)', position: 'absolute'},
    {transform: 'translate(200px)},
    {transform: 'translate(300px)},
    {transform: translate(100px), position: 'absolute'}]

The "prodigal" syntax is per-property:

   {<property>:[<value>|{offset?: 0.2, composite?: add, value:<value>}]*}

For example:

   {left: "100px"}
   {left: ["0px", "100px"]}
   {left: "100px", top: "120px"}
   {left: ["0px", "100px"], top: ["20px", "120px"]}
   {left: ["0px", "100px"], top: ["20px", {offset: 0.7, value: "120px"}]}
   {left: {offset: 0, value: "100px"}, top: ["20px", {offset: 0.7, 
value: "120px"}]}
   {left: ["100px", {offset: 0.55, value: "50px"}], top: ["20px", 
{offset: 0.4, value: "120px"}, {offset: 0.7, value: "100px"}]}
   {
     transform: ['translate(100px)', 'translate(200px)', 
'translate(300px)', 'translate(100px)'],
     position: ['absolute', 'absolute']
   }

The "chosen" syntax is closer to CSS. The "prodigal" syntax is 
particularly nice for lists of values for a given property. Would be 
nice to support both. Question, can we do this without complicating 
things too much?

Related question: Why does getFrames return the partially-normalized 
keyframes? We could match the specified / calculated pattern we have 
elsewhere.

Discussed possible return values including returning both "specified" 
and "computed" (i.e. normalized) keyframes.

Specified: May not include offsets when auto-distribute behaviour is 
desired. This is the preferred form if you want to add in extra 
keyframes and have them be automatically spaced. It is also nice because 
you can make assumptions about the structure of the data.

Computed (normalized): Allows you to inspect how keyframes got 
distributed and see which properties are supported etc.

Observation: Most JS animation APIs don't give you either. Presumably 
the thought is, "If you need the original object, hold onto it 
yourself". So if we were to only return one, it should probably be the 
computed value.

The computed/normalized result would follow the per-offset syntax. This 
will produce more intuitive results for keyframes coming from CSS. For 
input specified using the per-property notation we would split up the 
keyframes so there is one keyframe per property value to avoid offset 
alignment issues.

ACTION: Doug to work out what this would look like from an API point of view


3. ADD 'COMPUTED' AND 'SPECIFIED' TIMING FUNCTION DISTINCTION
=============================================================
(Shane)

This is partly based on the following use case involving paths:

Synchronizing with a paced path

  new ParGroup([
   // some complicated animation
   [red, blue, green]
   // a path animation
   [seg1, seg2, seg3]
  ])

Where do you put the 'paced' timing function? It doesn't work on the 
ParGroup, but won't apply to the complicated animation if placed on the 
path animation

 > This is interesting (not critical, but useful, and with some effort 
it can be worked around) but we will defer this to the separate spec on 
timing functions. We should also consider how to set this up declaratively.

(In particular, it is currently not too difficult to align animations to 
occur at certain points along a path animation based on *path length* 
but not based on *path segment*. That is, if you want to say, "this 
animation occurs when the paced path animation reaches this *point*", 
that takes a fair bit of calculation at the moment.)


4. ROADMAP
===========
(Brian)

Proposed focus for next draft:
* Fill modes: inheriting, snapshotting?, overflow?
   (Inheriting has already been added to the spec)
* Timing functions (chaining etc.)
* Events
* Timeline start
* Tighten up animation section
* Keyframes outside [0, 1]
(Issues in spec, bugs in bugtracker etc.)


5. CSS PROPERTIES, ANIMATION AND TRANSITION INSERTION POINTS, AND PAIN
======================================================================
(Doug)

Some important context:

(1) the CSSWG has resolved that CSS Animations should apply before 
!important properties, while CSS Transitions should apply after 
everything else:

UA Properties
User Properties
Author Properties
Inline Styles
CSS Animations (Override)
Author !important Properties
User !important Properties
UA !important Properties
CSS Transitions (Override !important)

Discussion here: 
http://lists.w3.org/Archives/Public/www-style/2013Jun/0682.html

 > Need to rework spec to bring this in to line with CSS resolutions. 
The "custom animation priority" hook may no longer be needed. Rather, a 
separate override stylesheet / stack may be needed.

(2) some CSS properties (hereafter called 'priority' properties) impact 
the computed style of other CSS properties IN THE SAME ELEMENT

For example, setting background-color: currentcolor will result in a 
computed background-color that matches whatever the color: property on 
the element is.

This means that CSS Transitions really do need to be inserted into a 
different magical style sheet to everything else, otherwise we can't 
meet the current specification requirements.

In particular, take the following case:

@keyframes foo {
     0% {
         color: red;
         background-color: currentcolor;
     }
     100% {
         color: blue;
         background-color: currentcolor;
     }
}

.foo {
     transition: background-color 2s;
     background-color: green;
     color: orange !important;

}

.foo.also {
     animation: foo 2s;
}

.foo:hover {
     background-color: currentcolor;
}

Imagine that you hover over a .foo, then after a second, some script 
applies the 'also' class.

For one second, the transition wins. This means that it finishes 
transitioning between green and the current color, which is orange. This 
in turns means that it needs to apply _after_ the orange !important 
declaration applies.

After this point, the transition no longer applies and the animation 
takes over. However, the animation applies before !important which means 
background color is transitioning between red and blue. This means that 
it needs to apply _before_ the orange !important declaration applies.

 > We should put a note about this into the CSS Integration spec.


6. PFWG REVIEW COMMENTS
========================

http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0008.html

 > Brian responded. Nothing to add at this point.


7. DEFAULT FILL MODE
===================

Recap: Need more input here. Shane preparing draft text used to elicit 
feedback.

Draft text as promised. This may not be concise enough.
------

Fill modes are a feature available in both CSS and SVG animations that 
allow the first or last value of an animation to apply either before, 
after, or both before and after the animation itself.

We're unable to determine what the default fill mode should be for the 
Web Animations API, as there are good arguments for making it none, 
both, or some 'auto' value.

On the one hand, the Web Animations API fill mode should default to 
'none' to match the defaults of CSS and SVG Animations. This will reduce 
the number of surprises web authors encounter when refactoring code from 
CSS or SVG into script using the Web Animations API.

On the other hand, our experience is that 'both' tends to be the fill 
mode used 80% of the time in practice when generating animations using 
script. Furthermore, when using timing groups[1], we have the following 
arrangement:
   child fill mode: 'none', parent fill mode: 'both' -> no fill
   child fill mode: 'both', parent fill mode: 'none' -> no fill outside 
the bounds of the parent
In order for a child of a group to fill indefinitely in a given 
direction, both it and all its ancestors need to fill in that direction. 
On the other hand, in order for a child of a group to not fill, only 
that child needs to specify a fill mode of 'none'.
Switching from 'none' to 'both' requires changing values throughout an 
animation tree, whereas switching from 'both' to 'none' can be done locally.

As a result, we'd like to get your input. Do you think we should:
  (1) choose a default fill mode of 'none' to match CSS and SVG?
  (2) choose a default fill mode of 'both' because it makes the API 
easier to use?
  (3) add an 'auto' fill mode that defaults to 'none' for animations 
(matching CSS and SVG) but 'both' for groups (making it easier to switch 
animations from 'none' to 'both')?

 > Brian to prepare some diagrams and send.


8. SHORTHAND PROPERTIES
========================

Recap: Need to work out how to prioritize shorthand properties. Should 
they always come first? Do they belong at all? Can we just assume they 
are expanded before they reach the model?

Brian: I think we can't rule out shorthands from the model because over 
time longhands often become shorthands. We can't have content break just 
because it was using something that was a longhand but is now a shorthand.


Next meeting: Thurs Aug 25 18:00 PDT / Fri 26 Aug 11:00 AEST / Fri 26 
Aug 10:00 JST @ https://etherpad.mozilla.org/PoetD3BlFl

Topics for next time:
* Making players stop
* Independent animation of transform components
* Additive/seamless/perfect animations
   http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0034.html

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

Received on Friday, 26 July 2013 05:27:21 UTC