[web-animations] Web Animations minutes, 27 April 2015

Web Animations minutes, 27 April 2015

Present: Doug, Shane, Brian
Archived etherpad: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.33376

Agenda:
1. Property-indexed keyframes
2. Finishing behavior
3. Publishing next WD
4. Negative infinity start delay
5. Add / accumulate -> Append / add?
6. Renaming time fraction
7. Readonly -> ReadOnly


1. PROPERTY-INDEXED KEYFRAMES
=============================

https://github.com/w3c/web-animations/pull/83

Shane:
I had thought that a property-indexed keyframe was just a keyframe with 
the same processing algorithm to convert from a JS object into a spec 
object.

Looking over it again, there's one minor modification that needs to be 
made for this to work. In 5.14.1 
(http://w3c.github.io/web-animations/#processing-a-keyframe-object) step 
10 we'd need to update the Member Variable part to first attempt to 
capture a list of things that are parsed as strings, then parse as a 
string if that fails.

I think this probably avoids a number of the other issues. WDYT?

On further discussion it seems like a PropertyIndexedKeyframe object is 
more desirable as it makes it clearer:
* what inputs are OK when; and
* what will be returned when Keyframes are extracted from KeyframeEffects.

 > Shane to have a go at rewriting the feature
 > Shane to remove reference to spacing keyframes


2. FINISHING BEHAVIOR
=====================

Thread starting: 
https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0013.html

* play() is probably ok for now

* ready is probably ok as a unified/re-used Promise for now but we need 
to look out for use cases that depend on knowing if a particular call to 
play()/pause() completed/rejected

It's hard to know if the re-using behavior is actually useful or not. It 
seems to help with some cases (independent modules performing different 
operations and then waiting on the ready promise) but in other cases may 
be less intuitive (e.g. calling play(), waiting on ready, then calling 
pause() -- authors might expect ready to reject in that case since the 
play() didn't complete).


* How about play-pending and pause-pending states?

We don't want to add too many states, especially since other operations 
may become async and require their own *-pending states. For now, just 
leave it as 'pending' and we can add 'pendingState' or some sort of 
substate if needed in the future.

* 'finished and paused'? finish()?

 > Make finished promise not resolve while paused
 > Make finish() take you to finished state (i.e. not paused)

* pause() while idle should resolve current time


3. PUBLISHING NEXT WD
=====================

Prerequisites:
* Try to get property-indexed keyframes in (unless nothing happens by 7 May)
* s/Readonly/ReadOnly/


4. NEGATIVE INFINITY START DELAY
================================

PR: https://github.com/w3c/web-animations/pull/87

 > Shane to look over


5. ADD / ACCUMULATE -> APPEND / ADD?
====================================

Concern that if you are combining independent animations, for example, 
you would "append" for filter lists but "add" lengths, i.e. different 
operation names for the same step.


6. RENAMING TIME FRACTION
=========================

Time progress / unit progress / unit time ?

unit progress fraction time :)

 > 'iteration progress' -> IDL: 'progress'


7. Readonly -> ReadOnly
=======================

To match geometry spec.

Received on Monday, 27 April 2015 05:17:26 UTC