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.
