[web-animations] Web Animations minutes, 9 Jan 2014

Web Animations minutes, 9 Jan 2014

Present: Dirk, Doug, Brian
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.-ZHzO6BebF-/latest

Agenda:
0. Meeting time
1. Status updates
2. Handling step timing functions at boundaries
3. Start of the document timeline
4. Test suite
5. Accessor for normalized property-specific keyframes


0. MEETING TIME
===============

11pm CET / 7am JST / 9am AEDST / 3pm PST might be a better time for 
everyone. Preferably on the same day as SVGWG telcon.

Brian to coordinate. Might consider making it 30min later.


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

Brian:
  - Replace CustomEffect with callback function
  - Prototype new player behavior (bounding at only one end) and 
completely rework player section in spec (added diagrams, replaced 
'playing' attribute with 'finished')
  - Start reworking animation section (making things interpolable by 
default, splitting out pacing, removing timing function chains etc. etc.)
  - Other minor edits from last meeting
  - Looking into start of the document timeline


2. HANDLING STEP TIMING FUNCTION AT BOUNDARIES
==============================================
(Brian)

Continuing from last time where we discussed this 
(http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0233.html, 
point 4) I went to make the change but noticed that special handling is 
needed in reverse.

For example, consider this case:

   new Animation(elem, [ { left: '100px' }, { left: '50px' } ],
       { fill: 'both', direction: 'reverse', easing: 'step-start', 
duration: 2 });

When we do the forwards fill we will be at active time = 0 since we are 
going in reverse. The time fraction passed to the timing function will 
be 0. Normally at t=0 the result is the top of the first step, but in 
this case we should be filling with the bottom of the step. So we 
actually have to take care of the *after* phase as well. The same 
situation occurs when we have a negative playback rate (and we also have 
to take care of direction: 'alternate-reverse' etc. and check what 
iteration we're in).

I've added wording for this to section 3.12.4 'Timing in discrete 
steps'. Please check it.


3. START OF THE DOCUMENT TIMELINE
=================================
(Brian)

Currently the spec says the document timeline starts at document load. 
That was based on the behavior of CSS Animations and SVG. Apparently 
no-one implements CSS Animations according to that part of the spec and 
everyone allows animations to start before document load. Also, for SVG2 
there has been a request to start animations before load.

Proposal: The document timeline starts after current document readiness 
changes to "interactive" and before dispatching the DOMContentLoaded event.

Doug: Why not make it the same as performance.timing.domInteractive from 
navigation-timing? That is, "the time immediately before the user agent 
sets the current document readiness to "interactive".

Use cases:

1) Animating a spinner while the document is loading (script/CSS)
Make it start at time zero and it will begin spinning when the document 
is interactive. Is that soon enough?

2) Animating a spinner for a really long document so it starts before 
the document is even fully parsed
Stick it in an iframe. Does that work?

3) Make an animation that starts onload from script
Set up a load event handler and trigger the animations then

4) SVG backwards compatibility--starting on onload
SVG will introduce its own timeline that is a child of the document 
timeline. By default this will start when the svg document fragment 
fires its onload event (which I presume is always after the document 
becomes interactive?)

5) SVG2--starting before onload
Provide a "timelineStart" attribute that allows the SVG timeline to be 
started at the same time as the document timeline.


If (1) is too late and (2) isn't a suitable workaround, we could tweak 
the proposal so that by default the timeline starts when the document 
readiness changes to interactive, but script can kick-start it before 
this time (either call start() or set started = true).


After further discussion, "interactive" is probably too late for some 
things like spinners which you want to start as soon as possible. On the 
other hand, making the zero time "as soon as you get the first byte of 
data" is too early if animations can be set up to start at time zero 
since by the time they start running they'll be half-finished.

One idea was to make the *document* timeline have its zero time at the 
earliest possible moment (e.g. first byte of data) but then the SVG 
timelines (which are nested under the document timeline) will still 
define their zero time later (e.g. onload event, or when the fragment 
has been parsed).

For CSS, *if* we decide to expose absolute start times then we could 
define what the zero time is then... or so I (Brian) though until Dirk 
raised the question of synchronizing SVG and CSS animations. For example,

<html>
   <svg>
     <circle>
       <animate begin="2s" ... />
     </circle>
   </svg>
   <style>
     div {
       animation-name: 'anim';
       animation-delay: 2s;
     }
   </style>
</html>

It seems like it would be nice to be able to line these up declaratively.

We talked about the general need to be able to synchronize CSS 
animations independent of SVG. If you have the same animation applied to 
two different elements then they may start at different times due to 
when the computed style gets resolved (which could be quite different in 
a large document).

So we considered the idea of exposing very simple timing groups to CSS, e.g.

   div {
     animation-group: 'abc';
     animation-name: 'bob';
     animation-duration: 3s;
     animation-start: 0s;
   }
   li {
     animation-group: 'abc';
     animation-name: 'fred';
     animation-duration: 3s;
     animation-start: 0s;
   }

Not sure if this really works and is scalable. If you later match some 
elements (after t=3s) they won't play since they are defined to run 
until t=3s which has already passed. So could you really re-use this for 
doing dynamic batches of changes?

The possibility of having very simple groups to synchronize CSS still 
seems attractive though since it is a big need. Any suggestions?

One further thought, in order to tie SVG and CSS times, it might be nice 
if you could do:

<html>
   <svg id="svg">
     <circle>
       <animate begin="2s" ... />
     </circle>
   </svg>
   <style>
     div {
       animation-timeline: url(#svg);
       animation-name: 'anim';
       animation-delay: 2s;
     }
   </style>
</html>

Or something like that but that still doesn't really solve the problem 
for coordinating just CSS animations. Maybe animation-timeline plus a 
@timeline rule?

One use case to consider is a batch of animations that run every time an 
event fires. You need a new instance of that timeline (actually group) 
every time. Needs more thought.

 > Probably document timeline should have its zero time at say, 
"domLoading". SVG will provide a different zero time based on this for 
each SVG document fragment and we will investigate ways to synchronize 
CSS-with-CSS and CSS-with-SVG.

 > We should also present this at the FXTF meeting in Seattle in Feb 29.


4. TEST SUITE
=============
(Doug)

We're interested in building/contributing to a shared test suite for the 
specification but don't want to begin this work until we're relatively 
confident that large curn in the spec is behind us.

What is still outstanding? If we're aware that certain sections will 
change significantly we can delay work there.

 > First step would be to set up repo and agree on 
templates/structure/format.


5. ACCESSOR FOR NORMALIZED PROPERTY-SPECIFIC KEYFRAMES
======================================================
(Doug)

Currently it's not possible to reflect on the normalized keyframes of a 
KeyframeEffect without reimplementing the algorithms for normalization 
and distribution.

A use case where this came up is a tool which edits and visualizes 
keyframes. Ideally the tool would be able to output the offsets chosen 
by distribution: eg. 
http://web-animations.github.io/web-animations-demos/components/web-animations-tools/wat-keyframe-editor/

Proposal: Expose normalized/distributed keyframes via a separate 
accessor on KeyframeEffect. This would be a similar pattern to the 
specified and computed timings exposed from TimedItem.

We might also rename getFrames to getSpecifiedFrames.

The output of the new accessor could take a few different forms. Some 
options:

Some examples given input of:
[
     {left: '0px', top: '0px'},
     {left: '100px', top: '100px'},
]

1. Property-indexed:
{
     left: [{left: '0px', offset: 0}, {left: '100px', offset: 1}],
     top: [{top: '0px', offset: 0}, {top: '100px', offset: 1}]
}

Pros:
- Easy to find all the keyframes for a specific property.

2. Flattened
[
     {left: '0px', offset: 0},
     {top: '0px', offset: 0},
     {left: '100px', offset: 1},
     {top: '100px', offset: 1}
]

Pros:
- Valid as input.
- Aligns with the accessor for the specified frames.

Brian: The reason why we provide the accessor that gives you the 
specified value is that if you supply keyframes without offsets meaning, 
"Space them out for me", then later fetch the keyframes to modify them 
and set them again, if the keyframes came back with the offsets filled 
in with their calculated values you would have to manually clear them 
again before setting in order to get the auto-spacing behaviour. So it 
would we really inconvenient if, for example, you want to get a list of 
three auto-spaced frames and insert another one while maintaining 
auto-spacing.

 > Probably we will end up adding both methods, but when Brian rewrites 
the pacing/spacing stuff we will consider if there is a way to, for 
example, have the computed offsets be returned but have a spacing mode 
of "auto-distribute" (or whatever we call it) override those values.


Next meeting: Thurs 23 Jan 22:30 UTC @ 
https://etherpad.mozilla.org/ztRZLhJS4g
   Local time: 
http://arewemeetingyet.com/UTC/2014-01-23/22:30/Web%20Animations

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

Received on Thursday, 9 January 2014 23:19:39 UTC