[web-animations] Web Animations minutes, 2 Oct 2014

Web Animations minutes, 2 Oct 2014

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

Agenda:

1. Should play() / pause() throw when there is no timeline / timeline is 
inactive?
2. Should pause() clear the start time and current time?
3. Should we be updating the start time while paused?
4. Editing the CSS integration spec
5. Should getAnimationPlayers, playState etc. flush style?
6. Renaming the keyframe offset property (it clashes with SVG)
7. Player sequencing - does it get reset when you cancel and restart?
8. Pausing CSS animations - not updating inline style
9. Readonly versions of interfaces
10. Drop motion path stuff?
11. Support negative infinity delay with infinite repetition?


1. SHOULD play() / pause() THROW WHEN THERE IS NO TIMELINE / TIMELINE IS 
INACTIVE?
==================================================================================
(Brian)

We allow setting the current time when there's no timeline or the 
timeline is inactive. If I pause(), then remove the timeline, it seems 
like I should be able to clear the pause flag before re-attaching to 
another timeline.

On the other hand, having play() throw when there's no timeline seems 
useful.

(Side note: I plan to update the procedure for setting a timeline so 
that it preserves the current time--that way you can swap in/out another 
timeline. That seems like the more useful behavior.)

What would the behaviour be if we did allow this?

Proposal: Puts the player in the pending state until you add a timeline?

General agreement this seems good.

 > Brian to try and spec this, may be more questions regarding the details


2. SHOULD pause() CLEAR THE START TIME AND CURRENT TIME?
========================================================
(Brian)

Seems weird that they temporarily disappear. It's not like they suddenly 
get less accurate. More to the point, it's nice if current time is only 
ever null when we're idle.

Shane: It's because of this anti-pattern:

   player.pause();
   var t = player.currentTime;

   // align something with t -> this will fail.

("fail" here means that for animations running on the compositor, things 
won't line up properly)

Brian: Even if we make currentTime null in this situation, you have the 
same problem if you reverse the first two lines.

Shane: If currentTime goes to null, people will realise something's 
wrong, and realise they need to wait on a promise.

   player.pause();
   player.ready.then(function() {
     var t = player.currentTime;
     // align something with t -> this is guaranteed to work.
   });

Dirk: I think it's weird, since author's need to know (this), and 
author's don't read the spec.

Shane: That's exactly why. Because author's don't read the spec we need 
to give them a clear signal that something's wrong.

Also, waiting on Promise returns is really inconvenient for scrolling 
through time.

(Lots of discussion about what is more understandable for authors and 
what is more likely to lead to content that works well across 
devices/browsers etc.)

Brian: What happens if you call player.source.computedTiming while 
waiting to pause?
Doug/Shane: It uses the hidden value of the current time to calculate 
the timing.

Some concern that for play() you can opt-out of waiting to play() with
   player.startTime = player.startTime
But with pause() you can't do
   player.currentTime = player.currentTime

Shane: It would be possible to introduce this behaviour, as a hack.
   player.currentTime = null <-- force the currentTime back to the 
internally tracked one.

Doug: why would you even?

 > No conclusion reached here. We keep the "current time becomes null 
while waiting to pause" behaviour for now but would like to find a 
better solution.


3. SHOULD WE BE UPDATING THE START TIME WHILE PAUSED?
=====================================================
(Brian)

And why do we only update the start time when pausing / unpausing? I forget.

Doug: We think that what should happen is that the start time is always 
null when the player is paused (or in pending state).

Shane: some invariants:

   pending state implies start time === null
   current time === null implies start time === null

Brian: Would be nice if current time === null implies playState === 
'idle' but oh well

 > Brian to update spec to make sure start time stays null while paused


4. EDITING THE CSS INTEGRATION SPEC
===================================

Brian working on exposing CSS Animations/Transitions through this API in 
Firefox. Would like to document some of the mappings / behaviour.

 > Shane to check this in as a subdirectory of the web animations github 
repo.


5. SHOULD getAnimationPlayers, playState ETC. FLUSH STYLE?
==========================================================
(Brian)

Basically, should this work:

   div.style.animation = "anim 1s";
   console.log(div.getAnimationPlayers().length); // prints 1

Brian: Checked this behaviour into Firefox a couple of hours ago.

Shane: I would really like that to work.

Doug, Brian: it does mean that you need to flush for lots of things:
  - playState
  - computedTiming
  - getAnimationPlayers
  - play()
  - etc.

Shane is OK with going in this direction, his only concern is if it has 
unavoidable performance implications that extend beyond using the CSSOM.

 > We will pursue this direction for now but revisit if there are 
significant performance implications.


6. RENAMING THE KEYFRAME OFFSET PROPERTY (IT CLASHES WITH SVG)
==============================================================
(Brian)

Background:

   elem.animate([ { color: 'blue', offset: 0 },
                  { color: 'green', offset: 1/3 },
                  { color: 'red', offset: 2/3 },
                  { color: 'yellow', offset: 1 } ], 2000);

'color' is matched with the CSS property 'color', but 'offset' is a 
special Web Animations keyword here meaning the keyframe offset.

In general we match the property names in these dictionaries as follows:

1) offset / easing / composite -> special Web Animations handling
2) something matching an animatable CSS property (e.g. 'marginLeft', 
'cssFloat') -> animate that property
3) something matching an animatable attribute name (e.g. 'd', 'href') -> 
animate that attribute

As we promote more SVG attributes to properties, (3) shrinks and (2) 
gets bigger.

However, in SVG there is an offset attribute which is animatable. It's 
an attribute on <stop> (gradient stop), <feFuncA>, <hatchPath> etc. It's 
quite common to animate it on <stop> or <feFuncA>.

Shane: What about svgOffset (cf cssFloat)?

Dirk?: What about making an exception here and saying, if we ever 
promote this to a property it's going to be 'stop-offset', so make 
people use 'stopOffset' instead?

Shane: I'd like this to be systematic, so you always know how to get to 
the version you want.

Doug: does this mean you should always be able to use 'css' and 'svg' 
prefixes?

Shane: Yes, I think so?

Shane: could also allow both stopOffset and svgOffset to resolve to the 
svg offset property.

Brian: We could also have this problem of a clash with 'composite' or 
'easing'.

Shane: People use 'offset' to mean keyframe offset a *lot* more than 
animating the offset attribute in SVG so we should prioritise that. I 
oppose renaming 'offset' to something like 'keyframeOffset'. Use 
'svgOffset' or 'stopOffset' or both instead.

 > We raise this topic now in case we need to rename the property name 
used to refer to the keyframe offset to something like 'keyframeOffset'. 
It seems like we won't do that so we can resolve on the exact mechanism 
for animating the offset attribute later.


7. PLAYER SEQUENCING - DOES IT GET RESET WHEN YOU CANCEL AND RESTART?
=====================================================================
(Brian)

This is referring to the player sequence number stuff. Seems weird that 
a player's position in the compositing stack is based on when it was 
created? Maybe not?

Shane: No. Tying sequences to actions in the API is a recipe for badness 
as we saw in SMIL And we should not do it.

(Didn't have time to discuss at length. May pick up this topic again later.)


8. PAUSING CSS ANIMATIONS - NOT UPDATING INLINE STYLE
=====================================================

Brian: we tried to make pause() and play() update the inline style (like 
we had previously discussed) but it didn't work - e.g. if you've got a 
list of animations specified then you need to somehow make the pause 
line up in a list when style changes elsewhere.

Instead, pause() on a CSS animation acts as a local override. If you 
call pause() then change the underlying rule, the call to pause() is 
sticky. play() overrides but is not sticky.

 > General agreement this seems reasonable and preferable to writing 
inline style but we need to see the details.


9. READONLY VERSIONS OF INTERFACES
==================================
(Brian)

This is the current plan right?

i.e. AnimationPlayer is read-write and AnimationPlayer.source returns a 
read-only object that you have to clone() before you make changes, at 
which point you break changes with specified style.

This saves having to record, for every property that maps to style, 
which ones have been overridden locally and which ones map to style. It 
also saves trying to introduce a mechanism that lets authors reset 
properties overriden by script. Basically, we only do this for 
animation-play-state because it is simple and maps to the 
AnimationPlayer instead of the Animation.

Dirk: This (adding read-only interfaces) tripled the size of the 
geometry specification.  The TAG requested to have internal 
representations. Some specifications have been using internal slots.

 > This still seems to be the way to go.


10. DROP MOTION PATH STUFF?
===========================
(Brian)

Proposal: Drop MotionPathEffect etc. in favour of the new Motion Path 
spec (currently at http://dev.w3.org/fxtf/motion-1/, in the process of 
moving to github) as a way of doing this.

Shane: +1000

We have https://github.com/w3c/motion-path/ but need to migrate from 
fxtf mercurial repo.

 > Doug to move fxtf/motion-path mercurial to github


11. SUPPORT NEGATIVE INFINITY DELAY WITH INFINITE REPETITION?
=============================================================
(Brian)

https://bugzilla.mozilla.org/show_bug.cgi?id=1043156

Shane: seems reasonable to be able to define an animation that runs 
forever and has always been running. So long as it takes into account 
iterationStart so that at currentTime 0 it lines up with iterationStart.

Brian: we'd have to change delay and startTime to be unrestricted doubles?

Shane: Probably ok.

 > Brian to look into allowing this.


Next meeting, TBD

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

Received on Friday, 3 October 2014 00:21:29 UTC