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

Web Animations minutes, 3 July 2014

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

Agenda:

1. How is the bikeshed conversion going?
2. Computed timing
3. Filling animations
4. Name property
5. Finished promise
6. Readonly version for CSS interfaces
7. Offset sorting, clipping, construction
8. Where are we up to with AnimationPlayer.startTime?


1. HOW IS THE BIKESHED CONVERSION GOING?
========================================
(Shane)

Waiting on nested list support.

Probably want to move it to GitHub too. Maybe do that first.

 > Shane and Doug to look into.

 > Shane to implement interface summarization first.

Doug: We'll likely just turn off the mirroring to 
https://github.com/web-animations/web-animations-spec and start doing 
the conversion there.
Shane: Conversion will probably only take a day.


2. COMPUTED TIMING
==================
(Brian)

As per 
http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0174.html item 
4, I added this to the spec 
(https://dvcs.w3.org/hg/FXTF/rev/651feaed027a), then a whole lot of 
discussion occurred about the DOMRectReadOnly pattern which I had 
blindly followed: 
http://lists.w3.org/Archives/Public/public-script-coord/2014AprJun/0246.html

I followed up with some questions here: 
http://lists.w3.org/Archives/Public/public-fx/2014JulSep/0000.html

 > Wait and see what feedback we get


3. FILLING ANIMATIONS
=====================
(Brian)

Previous discussion: 
http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0174.html item 3

Strawman proposal:

Behaviour:

* If there are 1 or more animations that fill forwards and are no longer 
current, the first player returned by Element.getAnimationPlayers 
returns that a player corresponding to the combined effect of all 
forwards filling animations. It has the following properties:
   - It is a regular AnimationPlayer pointing to a regular Animation as 
source
   - They Animation has a KeyframesEffect has 1~3 keyframes with a value 
for all of the forwards-filling properties.
        If *any* of the forwards filling animations for a given property 
have composite 'replace', the resulting fill value will be in a keyframe 
with composite 'replace'
        If *all* are 'accumulate' or 'add' they'd go in a separate 
keyframe with the appropriate composite mode
        Not sure what happens if all are either 'accumulate' or 'add' 
but it can probably be represented as one or the other.
   - The animation has duration Infinity (probably startTime -Infinity, 
not sure) (or does it just have fill mode)
* Other timing properties are set to some kind of defaults

It's important to use a player/animation that inherits from the regular 
interface so that script doesn't have to handle this case specially.

 From an implementation point of view, the UA basically needs to track 
just the composite "fill" value for each property that has 1 or more 
forwards-filling animations.

In the case where you have an animation stack like the following where 
all the animations have finished and are filling forwards:

    Animation F, add
    Animation E, add <-- script is keeping this object alive
    Animation D, add
    Animation C, add
    Animation B, add <-- script is keeping this object alive
    Animation A, replace

Changing the animation values / timing of B or E should affect the 
result as if animations A~F were still alive.

A UA could implement this by tracking the values for A, C+D, F but 
discarding the rest of the object state when these objects were garbage 
collected.
Note that it would need to do this even if Animation E had composite 
mode 'replace' since that could be updated by script.

The important point is that getAnimationPlayers would *still* only 
return one AnimationPlayer/Animation for the whole set and its keyframe 
values would represent the composite effect of A~F. If changes were made 
to E or B the keyframe values would be updated.

 > On further discussion, the problem seems to be with changing this 
summarised/filling player. What happens if you have a handle to a player 
forming part of the filling value but then you get a handle to the 
filling player and cancel it what happens to the one you had a handle on?

Use cases:
* understand the source of a filling value (Brian would prefer if the 
same approach works whether the animation is playing or filling but he 
might be dreaming)
* remove fill where the corresponding player is no longer reachable

 > Shane and Doug to try to think of an approach that doesn't hit the 
problems above.


4. NAME PROPERTY
================
(Brian)

Previous discussion: 
http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0141.html item 1

Proposal: It goes on AnimationEffect and we add a member to 
KeyframeEffectOptions and MotionPathEffectOptions. It is purely 
informational, setting it has no effect.

Rationale: It's a property of the effect. In CSS animation-name points 
to the effect.

If you put it on Animation, then I think you'd expect changing it to 
update the effect (which is pretty much how it works in CSS). However, 
that doesn't quite work since not every @keyframes rule is represented 
by the same KeyframeEffect object due to application of 
animation-timing-function. I think it's better not to create something 
that sort-of works like CSS but not quite (it's also different because 
you can't change effects on the fly with CSS).

Shane: I think the point is that this *is* purely informational, and 
therefore is *not* animation-name, which is a key. From a usage 
perspective it's much nicer on the animation. If 'name' and 
'animation-name' are too closely related lexicographically, we could 
call it 'label' instead.

 > There are different use cases here. Putting it on the effect makes 
sense for mapping back to CSS @keyframes rules but is less useful for 
animations generated by script (and probably SVG) where it seems useful 
for authors to be able to tag the *Animation* not just the 
*AnimationEffect* it is using. We can, of course, use expando properties 
for that but if we standardize a property for it then, for example, 
devtools on different UAs can report the same label.

Naming: label? ID is more idiomatic but these things will probably not 
be unique (e.g. when they are cloned, or spawned from a single <animate> 
element) so label might be better. Calling it "name" might cause 
confusion with AnimationEffect.name? (assuming that's what we call it 
there?) Maybe it's ok?

But 'name' is readonly for Function objects (and an 'effect' can point 
to a function). Is that ok that sometimes anim.effect.name is readonly?

Add member to KeyframeEffectOptions and MotionPathEffectOptions but what 
about the name on an Animation?

 > We probably want to add a name property to Animation and 
AnimationEffect but have yet to sort out details.

CSS integration spec will define how name automatically gets filled in 
for effects coming from @keyframes rules.


5. FINISHED PROMISE
===================
(Brian)

Previous discussion: 
http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0141.html item 2
and: http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0174.html 
item 2

I prepared a strawman proposal to get this moving.

 > Send to list.


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

 > Follow this up next time.


7. OFFSET SORTING, CLIPPING, CONSTRUCTION
=========================================
(Shane)

Summary: we should be strict or generous, but not sometimes one and 
sometimes the other.

 > Shane to describe this on the list and send two proposals.


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

 > Follow this up next time.


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

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

Received on Friday, 4 July 2014 01:38:42 UTC