Web Animations/Meetings/Meeting 15

From Effects Task Force
Jump to: navigation, search

Time, location: 26 Apr 16:30 PDT / 27 Apr 09:30 AEST / 27 Apr 08:30 JST, Skype + Etherpad

Log

Agenda:
1. Presentation in Hamburg
2. Renaming Timeline (back) to AnimationGroup
3. Renaming simple time to interval time
4. Grouping in animation addition stage
5. Revisit (briefly, I promise) percentages in end/duration.
6. Dmitry's feedback on the spec

1. Presentation in Hamburg

Positioning

a. CSS and SVG animations are pretty good.
b. But ... they don't work together. And they're not scriptable in any reasonable sense of the word.
c. Both the CSSWG and the SVGWG feel that this is a problem that should be addressed. There's been a few attempts in the past but it's a fundamentally hard thing to do.
d. 

List limitations of CSS and SVG, lack of good APIs for both.

Limitations in SVG:
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements

2. Renaming Timeline to AnimationGroup

Now  that Animations only have one function, we want to encourage authors to  use groups to share timing information. The idea is is both animations  and groups are lightweight things you use to build up the behaviour  required.

Reasons for preferring WebAnimationGroup over WebTimeline

1. Makes the relationship between WebAnimations and the things that group them more obvious.
2.  WebAnimationGroup sounds more lightweight. "I just want to group these  things so I can share the timing, I don't want to have to make a whole  new timeline!"
3.  The word "timeline" is a little confusing. I think to most people, the  idea of nested timelines is a bit of a paradigm shift. Normally we're  used to thinking of a single timeline (e.g. think history classes etc.,  or even just the UI of most animation editors)

Problems with WebAnimationGroup:
1.  WebAnimationGroupInstance is really long. But hopefully that's not a  type you actually write out often since you don't create the objects  directly.
2.  There was some reason we wanted people to be aware that groups had timing behaviour associated with them (hence 'timeline') but I can't remember what it was.
Alternatives:

    WebAnimation
    WebAnimationDef
    WebTimeline
    WebTimelineDef

    WebAnimation
    WebAnimator
    WebAnimationGroup
    WebAnimatorGroup

3. Renaming simple time / duration to interval time / duration

Currently  we distinguish between simple time and animation time. This roughly  parallels SMIL's simple time and active time (but "active" includes the  delay time for us, so I've renamed it to animation time which is just  the time when we're animating)
I think interval time is probably more intuitive. Likewise interval duration.

Note proposed changes to animation states:

Animation states:
* Inactive
* Active
* Chillin' like a villain

Animation states:
* Inactive
* Animating (active)
* Filling (active)

4. Grouping in animation addition stage

Defer until v2

5. Revisit (briefly, I promise) percentages in end/duration.

<animate intervalCount="5" duration="20%"/>
<animate intervalCount="5" end="untilContainerEnd"/>
Alex prefers having this over the keyword.

6. Dmitry's feedback on spec

* Need more examples

Brian explaining time containers...

<html>
   <animate delay="5s"/>
</html>

delay: 5s after the document loads

<html> <-- a type of animation group
   <par delay="5s"> <-- animation group
      <animate delay="5s"/>
   </par>
</html>

delay of the animation: 10s after the document loads