Web Animations/Meetings/Tokyo F2F Day 3

2012-03-30, Mozilla Japan, Tokyo

Present

• Shane Stephens
• Rik Cabanier
• Alex Danilo
• Brian Birtles

Minutes

(This is just a snapshot of the etherpad.)

Day 3, Web Animations Tokyo F2F 30 March 2012
Agenda: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings/Tokyo_F2F_Agenda
Topic: Review of Day 2?
Day 2: http://openetherpad.org/0Jr0qUXdI1
- If time, Brian would like to clarify whether a <par> type element, gives you an AnimationGroup object or an AnimationGroupTemplate object. Suggest the former with a pointer to the latter.
  -- have animate and animateWithParent on the AnimationTemplate object
  -- have animate on the AnimationGroupTemplate object which creates Animation objects from the children AnimationTemplate object passing in itself as the parent
  -- have <par> return an AnimationGroupTemplate object which has a notion of a primary instance that you can fetch to get the AnimationGroup object
- Like to talk about the TimedItem too
  -- talked about it
- And how to represent animation on a path in the API
  -- already discussed---need to consider this
  -- one possibility is to subclass the AnimationFunction object to have KeyFrameAnimationFunction and PathBasedAnimationFunction / TwoValuedAnimationFunction.
Topic: Addition
http://www.w3.org/Graphics/fx/wiki/Web_Animations/Additive_Animation
Clarification about different types of addition with regard to types. Note that transforms complicate things because if addition is defined as post-multiplication, "addition" is not commutative. Motion on a path may further complicate things due to the additional rotation (orient="auto"?).
http://brian.sol1.net/svg/animatetransform-issues/by-animation-and-scale-transformations/
Addition:
- When combining motion-on-a-path animations there are a couple of options both of which have value
1) Combining the two paths (T1 + T2), then calculating the normal vectors at each point and performing rotation according to these.
2) Rotating the inner path by the outer path's rotation (T1 x R1 x T2 x R2)
We can support both these use cases (AND MORE!) by separating path rotation out as a separate option. In this case, the first option is done by rotateAlong(path1 + path2), and the second by rotateAlong(path1) + rotateAlong(path2)
Blending:
- Blending is basically a weighted addition but where the weight varies over time
- We need basic support for this to implement "to animation"
- There are some complicated cases such as blending motion paths. This is mathematically pretty straightforward (use de Casteljau's algorithm to split the beziers etc.: http://en.wikipedia.org/wiki/De_Casteljau's_algorithm) but it might complicate the initial spec if we try to address it in the first version. We can probably defer this part and just support blending scalar values for the time being?
* Talking about stacking--the main problem with the SMIL sandwich model is that the ordering depends on begin time which is not intuitive to most developers
* Need to determine how a stack of blends and additions is calculated. Is there operator precedence here?
* Need to define a prioritisation model
Prioritisation:
- By separating the concerns of begin triggers and delay we can provide backwards compatibility with SVG and the sandwich model, whilst also providing a more intuitive prioritisation based on document order
- Delay does not affect prioritisation--it's basically instantiation time
-- animations with delays only (no begin / trigger) are instantiated immediately (and priority follows document order)
-- animations with triggers are added when the trigger fires (and are added to the top of the stack)
- For compatibility, we could have SVG element syntax support both the begin and delay attributes
- For the more generic element syntax, the HTML element syntax, we would probably only support delay
-- that would mean we don't have declarative triggers such as "a.click" but if they are useful we can added them in via a "trigger" attribute that is a subset of "begin" and overrides begin if both are specified
- In terms of providing backwards support for the sandwich model, it seems like it is possible to continue using the sandwich model provided animation generated by script etc. is annotated with a begin time corresponding to when it was generated.
Topic: Planning from here
Two targets:
(1) FXTF Meeting in Hamburg, 9th May
(2) SVG Open, mid-september. Deadlines: Abstract April 16th, Full paper: August 30th.
ACTION: Alex to write abstract for SVG Open.
May: 3 deliverables in mind:
* draft specification
* JS prototype
* presentation
Brian's out for 1 week.
Rik has limited availability but might have a week (he's working on a compositing presentation).
Next generation SVG & CSS animation
With the rise of the open web, each generation of browser introduces new exciting features from many web standard areas.
One of the most useful capabilities for web developers is animation in the browser.
SVG defined animation based on the SMIL model from the very first recommendation, whilst CSS animations were introduced more recently and are widely in use.
The obvious thing that is really needed in a web browser is a proper unified animation model to support both CSS, SVG and HTML content.
We have been developing an improved model for animation on the web which includes a Javascript API for convenience, CSS style rules for cascading control of animations as well as a powerful declarative syntax.
The new model is aimed to simplify the developer experience, being amenable to hardware acceleration as well as maintaining compatibility with existing animation in deployed browsers today.
We will cover the new animation model features, explain the APIs and present real world examples of it in use.
ACTION: Brian to turn these meetings' notes into delicious specification goodness.
ACTION: Alex & Shane to polish additive animations and specify.
ACTION: Alex & Shane to add information about reusing SMIL stack to technical note for SVG.
ACTION: Rik to furnish use cases for additive animations.
Other features we haven't discussed
* flexible timing (stretch to fix, pacing): maybe defer but think about how to do them.
* more timing functions: pretty simple and self contained (except maybe the JS api).
* reversing: should be specified by May. This could get tricky.
* speed control: just add an attribute and flesh out the details later.
* motion on a path - how to do this from an API perspective? Keyframes are an issue.
* general functional syntax - smoothly interpolate pairs of values other than just x and y, with a paced animation mode. Probably closely related to motion on a path.
ACTION: Brian to generate (most of) SVG technical note
ACTION: Shane to generate CSS technical note