W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

[web-anim] Web animations minutes, 14 / 15 March 2013

From: Brian Birtles <bbirtles@mozilla.com>
Date: Fri, 15 Mar 2013 13:46:17 +0900
Message-ID: <5142A799.5070001@mozilla.com>
To: "public-fx@w3.org" <public-fx@w3.org>
Web animations minutes, 14 / 15 March 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.0iJTmSakBaB/latest
Present: Dmitry, Doug, Shane, Steve, Brian

Agenda:
1. Status update
2. The specified TimingDictionary
3. Reverse behaviour
4. Is it add or accumulate?
5. How do we implement accumulating?
6. Clarifying the mapping re: to-animation
7. getCurrentPlayers/getCurrentAnimations


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

Brian:
  - Merged 'separate-api' back to 'default'
  - Still rewriting the spec, currently up to 'Animation values' 
(section 17)
    - Is GroupedAnimationEffect going away?
Shane: Yes, I think so. But we should consider either allowing 
KeyFramesAnimationEffect to target multiple properties or allow an 
Animation to have a list of effects.
 > Brian to investigate what to do in place of GroupedAnimationEffect

    - Ok to rename SplineTimingFunction to CubicBezierTimingFunction?
 > Seems ok

  - Interesting email thread for the week: 
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0634.html 
- reflections on IndexedDB API
  - Dirk Schulze is offering to help port our changes to respec to the 
current version on github (v3) -- yay! Thanks Dirk!

Doug:
  - Polyfill stuff... naming is closer to spec.
  - Polyfill now works in Firefox and IE9/10!

Steve
  - Fixed a few polyfill bugs
  - Added basics of media integration
  - Merged new test framework

Shane
  - Polyfill stuff
  - new test framework works in firefox and IE9/10
  - getting close to switching over to new framework


2. THE 'specified' TIMING DICTIONARY
====================================

Recap: dictionaries in WebIDL are static. So we can't just reuse the 
TimingDictionary interface for representing timing parameters on TimedItem.

Options:
(a) Make a Timing interface to mirror the dictionary but which is live
(b) Put the members directly onto TimedItem
(c) Put the members directly onto TimedItem and put computed timing in 
another object - ComputedTiming
(d) (a) and (c) -- i.e. put specified and computed timing in other 
interfaces
(e) Have a method to update specified timing: 
updateSpecifiedTiming(dictionary)
(f) Extend WebIDL (+1)
(g) Sidestep the problem with a different WebIDL construct or 
ECMAScript-specifics - see 
http://www.w3.org/TR/geolocation-API/#position_options_interface and 
http://www.w3.org/TR/2010/WD-WebIDL-20101021/#Callback

 > Brian to email Cameron to see what our options are
 > Shane to follow up with Elliot and others


3. REVERSE BEHAVIOUR
====================

Recap: We had/have Player.reverse() but Brian thinks its useful to have 
a means of reversing something so that if it has already finished, it 
begins reversing from the end. So, if it finished 3s ago, it doesn't 
wait 3s, but starts reversing straight away. If it's in the middle of 
its animation, it just reverses from its current point.

But that makes Player depend on its source content which currently its not.

Strawman proposal:

Add methods that are explicitly dependent on the source content?

Player.reverseSource()?
Player.pauseSource()?

That might remove the expectation that calling reverseSource() twice is 
a no-op even after the item has finished.

pauseSource() if added could provide the previously defined behavior 
that doesn't pause outside the source's active interval.

if (player.currentTime > player.source.endTime) {
     player.currentTime = player.source.endTime;
}
player.playbackRate *= -1;

➙ Opposition to adding reverseSource. Brian to add an issue about the 
possibility of adding this method. Will revisit based on usage in the wild.


4. IS IT ‘add’ OR ‘accumulate’?
===============================

‘accumulateOperation’ is the name of the property that describes how 
animation values are calculated from iteration values. ‘Add’ is the name 
of the operation used.


5. HOW DO WE IMPLEMENT ACCUMULATING?
======================================

Accumulate to be a boolean that is implemented inside Effect (i.e. 
before the value gets sent to the compositor stack).


6. CLARIFYING THE MAPPING RE: TO-ANIMATION
==========================================

If I have:
   var anim = new Animation({ top: '200px' }, 3);
do I get a to-animation? Yes: ['200px', '200px'] merge

What about
   var anim = new Animation({ top: [ '200px' ] }, 3); ? No: ['0px, '200px']
or
   var anim = new Animation({ top: [ '0', '200px' ] }, 3); ? No: ['0px', 
'200px']

new Animation({ top: [ '200px' ] , operator: "merge"}, 3); ← not a 
to-animation
new Animation({ top: [ '200px' ] , operator: "add"}, 3); ← adds 200px 
over 3 seconds

Brian's proposal: Change this so that we flat-extend out to 0 and 1 from 
the closest specified keyframe (i.e [{0.6: '200px'}] acts like ['200px', 
'200px'] and [{0.3: '100px'}, {0.6: '200px'}] becomes [{0: '100px'}, 
{0.3: '100px'}, {0.6: '200px'}, {1: '200px'}]

Brian: Looking at CSS, it fills in 0% and 100% (if needed) with a 
keyframe that corresponds to the current computed value of the property. 
I think we should match CSS here.

➙ Decided we will try to mimick CSS here. Basically, if there is no 
keyframe at the endpoints then the animation effect generates the 
suitable value and tells the compositor to use a merge operation. 
Basically, it will do what CSS does here.

Revisiting earlier examples:
   var anim = new Animation({ top: '200px' }, 3);
Gives you:
   { 1: '200px' }
Which will perform a merge (since there's no 0)

But:
   var anim = new Animation({ top: '200px', operation 'add' }, 3);
Still gives you a merge (since there's no 0-keyframe rule)

 > Continue next week


7. getCurrentPlayers/getCurrentAnimations
=========================================

 > Next week


Next meeting: Thurs Mar 21 15:00 PST / Fri 22 Mar 10:00 AEDST / Fri 22 
Mar 08:00 JST @ https://etherpad.mozilla.org/pHPfOqZA75

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 15 March 2013 04:51:01 GMT

This archive was generated by hypermail 2.3.1 : Friday, 15 March 2013 04:51:02 GMT