[web-anim] Web Animations minutes, 16 / 17 May 2013

Web Animations minutes, 16 / 17 May 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.eUtb$hsAAim/latest
Present: Doug, Shane, Steve, Brian

Agenda:

1. Status update
2. F2F dates
3. Fill mode use cases
4. Other feedback
5. Path animation
6. Animatable properties / types
7. Keyframe offsets outside [0, 1]
8. Timing hierarchy manipulation
9. Qualities of target properties
10. Accumulation
11. Timing calculations in the spec


1. STATUS UPDATE
================

Brian:
- Removed event propagation
- Remove special pause behavior that applied before a player's start time
- Reworked interaction with script section
- Added TimedItem.parent member (oops!)
- Fixed(?) time fraction calculations (thanks Doug and Shane!)
- Reworked interaction with page display section
- Addressed some review feedback (renaming concepts in animation model)

Doug:
- Still working on timing calculations.


2. F2F SCHEDULE
===============

Web Animations F2F: Mon-Tues 27-28 May, Fri 31 May @ Mozilla Japan

Target: request for FPWD on Wed 29 May.


3. FILL MODE USE CASES
======================

Possible example:

   new Animation(target,
     { position: 'absolute', left: '0px', top: '0px' },
     { position: 'absolute', left: '100px', top: '100px' },
     { fillMode: 'none', ... });

But underlying value has position: auto, etc.

Basically, anywhere you want to control the movement of something from 
one predetermined state to another, but don't want the Animation to 
control the position after that point. This is a common effect where you 
want the animation simply to be a cosmetic overlay for an underlying 
change in state.

However, we're specifically looking for cases of fill: none inside fill: 
forward.

 > We don't really have any concrete examples of use cases where parent 
is fill: forward and child is fill: none but we suspect that in this 
case it is more intuitive for the child's fill: none to be respected. 
Experience in the polyfill also suggests this behavior is less likely to 
produce inconsistencies at interval boundaries due to floating-point 
inaccuracy.

 > Brian to spec out fill: none on descendant always being respected.


4. OTHER FEEDBACK
=================

We (Google Sydney) have a doc with other feedback 
(https://docs.google.com/document/d/1bOsBLoyZ_toIOiU_uIbepXPRzoKkUKmcN0tR4HcHYOw/edit). 
We've already added information about some of the larger threads from 
our review. Here's some more minor ones:

1) The specification is currently written in a way that implies lots of 
things are not animatable. We think it's better to allow everything to 
be animatable and define default animations that are step animations. 
This allows for some interesting tricks like setting position: absolute 
for the duration of an animation.

 > Discussion moved to section 9.

2) Accumulation doesn't seem to be quite right at the moment. For 
example, imagine animating to 50px with an underlying value of 100px. 
Some valid accumulation behaviours could be:
  a) keep animating linearly (i.e. 100px -> 50px in the first iteration, 
50px -> 0px in the second)
  b) 're-apply' animate-to (i.e. 100px -> 50px in the first iteration, 
50px -> 50px in the second)
What is currently specced will do 100px -> 50px in the first iteration, 
150px -> 50px in the second.

 > We will try to spec (b) for now, that is, use the final value of the 
previous iteration as the underlying value. We hope this can be 
implemented without having to actually calculate the final value of 
every iteration.


5. PATH ANIMATIONS
=================

We have a draft spec: 
https://docs.google.com/document/d/1D40pVzgWeYCivDxG6FFKgiZW7p4CuE_395iT8sTMklo/edit

We decided to try doing this section entirely by-reference to SVG Paths. 
Is this OK or should we try something different?

 > Answer: Not ok; it would make SMIL a normative reference.


6. ANIMATABLE PROPERTIES / ANIMATION OF PROPERTY TYPES
======================================================

We have started writing this section. It's in the same doc as path 
animations.

I'd really like to know whether this is going in the right direction or not.

 > Discussed under section 9.


7. KEYFRAME OFFSETS OUTSIDE [0,1]
=================================

Revisiting this from last time. Any thoughts?

Brian to follow up next week with Mozilla. Shane to try and get some 
comments from Tab.


8. TIMING HIERARCHY MANIPULATION
================================
(Brian)

There are two issues here:

A) Removing a node is *really* hard, i.e.

    anim.parent.remove(anim.parent.indexOf(anim));

I think that deserves a medal for worst API ever.

So, I thought, why not add a version of remove() that takes a TimedItem 
giving you:

    anim.parent.remove(anim);

Which looks a lot like how people use the DOM but that lead me to (B)

B) Recent additions to DOM (DOM4/dom.spec.whatwg.org) changes the way 
this stuff works

Now we have,

   node.removeChild() - Removes the child (marked as 'legacy')
   elem.remove() - Removes the element from the parent (new)

Likewise,

   elemA.replace(elemB) - Replaces elemA with elemB amongst 
elemA.parentNode's list of children
   elemA.after(elemB) - Inserts elemB into elemA.parentNode's list of 
children after elemA
   elemA.append("hello") - Appends the text node "hello" as the last 
child of elemA's list of children

I think we ought to align with this. That might mean:

* Renaming TimedGroup.remove to removeChildren, and/or
* Making TimedItem.remove remove from the parent
   (It might make sense to have Player.remove() detach from the timeline)
* Replacing TimingGroup.add with append/prepend
* Consider removing splice

Shane: YES. The new API is so much nicer.

 > Brian to have a go at reworking TimingGroup to line up with new DOM 
methods

Also discussed splice, will leave out for now, easy to add later.

One use case to bear in mind is the following: I have a sequence group 
used to do a kind of frame-based animation where each child animation 
shows an image for a short-time. I want to extend the sequence by adding 
100 more frames. Calling 'append' 100 times is going to be slow.

One work-around for the time being would be to construct a new sequence 
group (the constructor for a sequence group takes an array of timed 
items) and append the new sequence group to the existing one. It's a bit 
messy but we can easily add splice later if needed. It's much harder to 
remove it.


9. QUALITIES OF TARGET PROPERTIES
=================================

There seem to be a few different ways of seeing things:

A ("The CSS/SVG way" ?):
- Some properties are animatable, some are not
- Some types are interpolable, some are not
- Some types are additive, some are not

More specifically:
- Some properties are animatable, some are not
    - CSS: if it's not marked as animatable, or it is "Animatable: no" 
then it's not animatable
    - SVG: some are marked explicitly as not animatable
       e.g. direction, enable-background, glyph-orientation-horizontal, 
glyph-orientation-vertical, unicode-bidi, writing-mode
- Some types are interpolable, some are not
   - CSS: some combinations of values are interpolable, some are not
   - SVG: "The default mode is 'linear', however if the attribute does 
not support linear interpolation (e.g. for strings), the ‘calcMode’ 
attribute is ignored and discrete interpolation is used." - basically 
SVG says everything is interpolable (but don't necessary support linear 
interpolation)
- Some types are additive, some are not
   - CSS: n/a
   - SVG: Some *types* are additive, some are not (e.g. frequency, time)

B ("The mathematical way" ?):
- Everything is animatable, except the things that aren't
- Everything is interpolable, but sometimes only discrete interpolation 
is available
- Everything is additive, but sometimes addition just returns the RHS

Discussed approach B. The first, part is probably fine, i.e.

 > "Everything is animatable unless otherwise stated"

 > Brian to rework existing stuff about properties to make it say things 
are animatable by default

The others may be ok to, but we'd like to see how they shape up when 
spec'ed out. We'd like to provide the necessary hooks/definitions so 
future specs can say, for example, "this property is able to be linearly 
interpolated but attempting to add it simply returns the value being 
added" or something of that sort.

 > Google Sydney team to rework draft animatable properties section in 
light of this


10. TIMING CALCULATIONS IN THE SPEC
===================================

Deferred a number of issues until F2F / IRC but briefly discussed the 
following:

* Shane + Steve thought currentIteration should be null outside the 
active interval (even when filling)

Current iteration could include the time fraction? Might be better 
called "progress".
  i.e. progress (double): <current-iteration>.<time-fraction>

The difficulty with this is it doesn't accommodate the situation where 
you are applying the final value (e.g. fill: forwards).

It might not be so difficult to detect those situations though in the 
animation model and handle accordingly. Needs further investigation.


Next meeting: Mon May 27 9:00 JST @ 
https://etherpad.mozilla.org/T1VWmY82NH / Mozilla Japan

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

Received on Friday, 17 May 2013 04:33:30 UTC