[web-animations] Web Animations minutes, 10 July 2014

Web Animations minutes, 10 July 2014

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

Agenda:

1. AnimationPlayer interface changes
2. Readonly interfaces and inheritance
3. null vs NaN
4. Readonly version for CSS interfaces
5. Where are we up to with AnimationPlayer.startTime?
6. KeyframeEffect handling


1. ANIMATIONPLAYER INTERFACE CHANGES
====================================
(Brian)

Proposal:
http://lists.w3.org/Archives/Public/public-fx/2014JulSep/0007.html

Update: Enum value "playing" should be "running"
Also I'm pretty sure we need a "ready" promise for animations that take 
a while to start

Doug: On states, should we call out 'pausing', 'reversing', and 
'starting' as different states rather than just 'pending'?

Brian: I think have too many states makes the API hard to use since 
authors have to check them all, and probably isn't useful.

Shane: if you reverse then reverse in the same code block, are you 
pending or not?

 > Maybe. Needs more thought and experimentation. Either way, this needs 
to be specified.

Doug: Why do we need to rename document.timeline.play if we wish to keep it?

Brian: This was just in response to TAG feedback which suggested that 
since play doesn't play the timeline this naming doesn't make sense. cf. 
Element.animate which animates the Element.

Shane: Not sure I buy this argument. I'll follow-up on the list.

Doug: Is this similar? Promise<ServiceWorker> 
ServiceWorkerContainer.register(ScalarValueString scriptURL, optional 
RegistrationOptionList options);

Doug: Why not just one promise, which would resolve when we go out of 
the pending state.

 > We want the following behavior:
- Same promise returned by all the methods which can put us into the 
pending state.
- This promise should be the same object as the ready attribute.
- The promise should resolve to the player, so we can chain:

   timeline.play(foo).ready.then(function(player) { ... })

Question: Is it ok to drop finish events?

Some discussion about when promises get resolved. Probably it's ok to 
drop finish events.

Some discussion about whether the finished promise gets resolved when 
you cancel() and, in fact, what cancel() actually does.

We think it's probably best if cancel():
- Sets the state to idle
- Makes the startTime unresolved (i.e. NaN)
- Does *not* resolve the finished promise (since we don't enter the 
finished state)
- Does *not* disassociate the source content (since that was only 
necessary when we didn't have an idle state and needed a way to disable 
the player)


2. READONLY INTERFACES AND INHERITANCE
======================================
(Brian)

Thread starting here:
http://lists.w3.org/Archives/Public/public-fx/2014JulSep/0000.html

Domenic's feedback:
http://lists.w3.org/Archives/Public/public-fx/2014JulSep/0009.html

My current thinking:

    [Constructor (AnimationTimingInput timing)]
    interface AnimationTiming {
      attribute FillMode fill;
      attribute (unrestricted double or DOMString) duration;
      ...
    };

    dictionary AnimationTimingInput {
      FillMode fill = "auto";
      (unrestricted double or DOMString) duration = "auto";
      ...
    };

    dictionary ComputedAnimationTiming {
      double FillMode fill;
      double duration;
      unrestricted double timeFraction;
      ...
    };

    interface AnimationNode {
      readonly attribute AnimationTiming timing;
      ComputedAnimationTiming  getComputedTiming();
      ...
    };

Notes:
* No inheritance -- just maintain consistency by hand
* Since ComputedAnimationTiming is independent of AnimationTiming(Input) 
we can make duration just a double
* getComputedTiming() returns a snapshot dictionary -- not sure if this 
causes confusion for users of getComputedStyle() which returns a live object
* Prefer ComputedAnimationTiming to CurrentAnimationTiming since more 
than half of the members are not dependent on the current time
* I've gone with a method for getComputedTiming since we're returning a 
dictionary. (Is that right? Can't use a dictionary as an attribute right?)

Shane: Does AnimationTiming need to be readonly on AnimationNode? It's 
actually nice to be able to share timing across multiple animations, and 
we have no way to do that right now.

Brian: I just did that because Domenic didn't seem to think it was 
necessary for it to be writeable. I'm ok with making it writeable but it 
adds implementation complexity (tracking shared objects etc.).

 > Let's make it writeable for now and if implementation experience 
proves this is complex then we can defer it.


3. NULL VS NaN
==============
(Brian)

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

Somewhat reluctantly leaning towards NaN. Reluctant because sometimes 
the null -> 0 behavior is useful. And also because for writeable 
attributes, setting null is somehow more intuitive than setting NaN.

Shane: Here's an example of where the null -> 0 behavior is really bad:

   var player = timeline.play(...)
   player.startTime += 1000; // move this 1 second into the future ... 
or not :)

 > Go with NaN


4. READONLY VERSION FOR CSS INTERFACES
======================================
(Brian)

I thought we were in agreement that for AnimationPlayers corresponding 
to animations generated by CSS markup, the source attribute pointed to a 
read-only Animation such that all of its members were read-only. If you 
wanted to change anything about it you'd have to clone it, change it, 
then set the source to the new object. That way you don't end up with a 
weird state where the Animation object partially masks changes to the 
markup.

Is that right or has something changed?

 > Probably ok.


5. WHERE ARE WE UP TO WITH AnimationPlayer.startTime?
=====================================================
(Brian)

We talked about making this go null or NaN when the player is waiting to 
start. Then there was some discussion about doing similar while waiting 
to pause. And I had a feeling there was further suggestion about 
simplifying these properties. Is that right? Where are we up to here?

Shane: our experimental implementation currently has 3 states:
(1) you're playing. currentTime + startTime = timeline.currentTime
(2) you're paused. NO START TIME (i.e. unresolved). currentTime is 
paused time
(3) you're finished. Start time is a historical record of the time you 
started.

Brian: Should (2) have a continuously updating start time instead? Hmm, 
maybe it's simpler for it to be NaN.

 > Brian to try working this into the spec.


6. KeyframeEffect PROCESSING
============================
(Shane)

http://lists.w3.org/Archives/Public/public-fx/2014JulSep/0010.html

Brian:
Things not covered in the details of (2)
* constructing keyframes at 0 or 1 if none exist: actually this isn't 
changed

Shane:
Something Eric brought up with regards to (2):

If you have:

   keyframes.map(function(k) { return k.offset; }) -> [null, -1, 2, null]
   add 0 or 1 keyframes --> [0, -1, 2, 1]
   sort --> [-1, 0, 1, 2]

We could modify the 0/1 fixup to only occur if there are no keyframes 
outside the range [0, 1] and that would solve this (spacing also needs 
to be able to be one-sided).

 > Probably best to go with strict handling initially. We can probably 
relax that handling later without breaking content. We should also add a 
note to the spec mentioning that we will probably allow offsets outside 
[0,1] in future.


Next meeting, Thurs 17 July 2014 07:00 UTC
   Local time: 
http://arewemeetingyet.com/UTC/2014-07-17/07:00/Web%20Animations

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

Received on Friday, 11 July 2014 00:50:49 UTC