View source for Web Animations/Meetings/Meeting 6

Time, location: [http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=2&day=22&hour=0&min=0&sec=0&p1=234&p2=240&p3=248 21 Feb 16:00 PST / 22 Feb 11:00 AEDT / 22 Feb 09:00 JST], [irc://irc.w3.org:6665/%23webanimations #webanimations]

== Agenda ==

# Inverse Kinematics - Rik
# [[Web Animations/API Primitives|API / Object primitives]]
# [[Synchronization Approaches Discussion|Synchronization discussion]]
# <del>Accessibility - Shane</del>

== Log ==

<pre style="white-space: pre-wrap">
<shans> hey guys
<birtles> hi Shane
<birtles> Rik, you ready to meet?
<cabanier> yes
<birtles> great
<birtles> tentative agenda: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings/Meeting_6
<birtles> basically:
<birtles> 1) API / Object primitives
<birtles> 2) Synchronization discussion
<birtles> 3) Accessibility
<birtles> 4) Inverse Kinematics
<shans> lgtm
<birtles> we probably won't cover it all today though
<birtles> any preferences for order?
<birtles> or other items to add?
<cabanier> let's do 4 first because it will be quick
<birtles> ok, inverse kinematics it is
<birtles> did you discover anything?
<birtles> e.g. existing specs?
<cabanier> I did some asking around and it turns out that IK is used very little
<cabanier> most users find that it doesn't give them enough control
<birtles> interesting
<cabanier> so they end up doing it manually
<cabanier> The demos look very cool, but in the real world people don't really like it
<birtles> wow, so I guess it's P4 then?
<cabanier> yes
<cabanier> and I think we can focus on shape morphing instead (as a p3/2)
<shans> righto, in a way I guess that's good - we don't need to concentrate on an additional complicated technology
<cabanier> yes
<birtles> yeah, sounds good
<birtles> so shape morphing is what we already have under "Simpler animation between two paths" ?
<cabanier> people are preferring regular animations to create characters
<cabanier> correct
<birtles> ok, sounds good then
<birtles> well, next item is (1) then?
<cabanier> yes
<birtles> API / Object primitives
<birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/API_Primitives
<birtles> shans, I sneakily updated the page about 10min before the meeting :)
<shans> hah
<birtles> I think the main issue we were discussing here was the stacking behaviour?
<birtles> is that right?
<shans> reading it now
<cabanier> you added a lot
<shans> yeah
<shans> sorry :)
<birtles> and also whether Animator objects affect the CSS style declarations
<cabanier> :-)
<birtles> cabanier, I only added about 1 paragraph before the meeting :)
<shans> so, I think we really do want the API to map to each CSS rule, yes
<birtles> why is that?
<shans> 2 reasons
<shans> it'll take me a bit of time to compose my thoughts here, so sorry
<birtles> take your time, it's important
<shans> but (1) we want to convince the CSSWG to expose as much of the capabilities that we offer as possible (same with SVGWG). A close mapping makes this more likely.
<shans> (2) we want to give developers an API that makes it convenient for them to continue to declaratively specify animations, then work with them in script. It's OK for them to go back to the CSSStyleDeclaration to tweak stuff that CSS exposes, but I really think we need to let them attach - at the style rule level - changes to animators which aren't yet exposed by CSS too, in order for the API to feel integrated.
<shans> for a simple example of (2), consider making a CSS transition additive.
<shans> (do you want me to explain that example?)
<birtles> oh, sorry, I thought you were about to
<shans> :)
<birtles> umm, let me think about (2) for a moment
<shans> ok
<cabanier> when you say the API should map to each CSS rule, what do you mean?
<birtles> with (1) I'm not sure it's such a big deal, but I probably need to think about that a bit more too
<cabanier> that it should reflect what CSS has or that you can retrieve where the value came from 
<birtles> cabanier, if your animation is defined by a number of CSS style declarations (combined together) do you get one Animator per declaration?
<birtles> or just one Animator for each target element?
<shans> what I mean is that (1) each CSS rule (i.e. <selector> { [<property>:<value>] }) that sets the value of a transition property generates an Animator, and that (2) these Animators stack in the same way that CSS rules stack to generate the final outcome. There's actually a couple of examples at the bottom of the API_Primitives document that explore this relationship.
<birtles> woah, I don't think I even saw that section :)
<shans> SNEAK SECTION!
<cabanier> ah
<birtles> ok, Im about to read through that section now, but I think one use case that deserves attention is getting the animator on a particular element and changing its parameters easily without affecting others
<birtles> I would imagine that to be the most common use
<shans> yes, that case is handled with this proposal
<shans> btw you probably didn't see that section because I only added it this morning. I apologize for not doing it sooner - but I have an excuse too! My laptop up and died the night before last and I'm scrambling to get a replacement. :)
<birtles> Ok, I still don't quite get (a) how the use case is handled, (b) why stacks are "necessary"
<birtles> with regards to (a), doesn't changing an Animator in this case affect the style rule?
<cabanier> a stack is needed because animators can be compounded
<shans> yeah
<shans> the second use case demonstrates the need for the stacks, I think
<shans> for your question, brian - which Animator?
<birtles> if you get the Animator corresponding to an element
<birtles> I think you expect changing the Animator to just affect that element
<shans> and that's what will happen
<shans> if you access the underlying 'stack' which that animator is constructed around, then different story. But if you modify that animator directly, then you're only modifying the animation for that element.
<cabanier> I guess an animator can apply to many elements
<birtles> so you basically have Animator (element style) -> Animator (style declaration) -> Animator (style declaration) ?
<cabanier> so, changing an animator that is in the stack, will also change the animator that was constructed with that stack?
<shans> yeah
<shans> wait
<shans> yeah to Rik
<shans> to Brian, you have a list of animators that come from element style and the style declarations that impact the element.
<shans> yeah
<birtles> right, isn't that what my "diagram" shows?
<shans> I think so
<shans> but
<shans> BUT
<birtles> :)
<shans> that list is passed into the constructor of another Animator that represents the element'
<shans> s current animation
<shans> so you actually have:
<shans> Animator([Animator from explicit style, Animator from low-specificity style declaration, Animator from higher-specificity style declaration, ...])
<cabanier> does the constructor resolve the order itself, or is it purely based on the order
<birtles> so it's the difference between an array or a linked list we're talking about
<cabanier> seems like the constructor should figure it out
<shans> no, CSS is responsible for resolving the order. The constructor just jumps down the list
<shans> Brian: not sure
<shans> the important thing from my point of view is that there's an Animator for each style declaration, and another one that generates the actual animation.
<birtles> hmmm... so in the future it would be nice if different declarations can set up animations on different properties
<shans> what do you mean by that?
<birtles> I don't know
<birtles> wait a second :)
<cabanier> it seems like the stack approach allows that
<cabanier> it doesn't even have to be with the stack
<birtles> I'm just trying to think about how additive animation fits into this model
<birtles> but basically, I'm still struggling to see why this is necessary
<birtles> it seems complicated
<cabanier> shane, the Animator for each style declaration can generate an animation too, correct?
<shans> in principle, yep
<shans> Brian: you might be right in that there's a simpler approach. If you have one in mind, could you apply it to the two simple examples that I've set forth at the bottom? Then we could compare and contrast.
<birtles> ok, first I have to summarise the examples to see I understand
<birtles> wait, so the first example is what Animator objects exist and when they are generated for the given style declaration
<shans> yeah
<birtles> ok, so we have <a class="foo">
<shans> and the second example takes a more complicated piece of CSS and applies the same approach
<birtles> one possible approach (which I haven't thought through yet) is you call window.getAnimatedStyle(elem) and you'd get an Animator
<shans> Why don't you put a counterproposal in the doc and we can discuss at the next meeting?
<birtles> yeah, ok
<cabanier> yes, there will should be a factory method that create animator based on a style, var myanimator = createAnimatorFromStyle(".foo")
<shans> that'll give you a chance to think the approach through fully
<birtles> yeah, I haven't really thought much about transitions
<birtles> mostly about animations
<shans> animations are easier because they don't rely on current values as much
<shans> but they still (imho) need the stacking approach :-)
<birtles> ok, my action: annotate the simple css case study with an alternative approach
<cabanier> then if you call  createAnimatorFromStyle(".foo:hover"), you get a stacked animator back
<birtles> I think the reasons you outlined earlier for the stacking approach didn't suggest we "need" stacking, just that it would be nice (1) politically, (2) to help when CSS doesn't support something in the API
<shans> not politically, no
<shans> well also politically :)
<shans> basically by conforming cleanly to CSS and SVG specs we make it technically easier to adopt new features
<birtles> strategically then
<shans> yeah
<shans> that's a good word
<birtles> :)
<birtles> alright, I'm not opposed to the idea
<cabanier> I think it sounds like a good approach
<birtles> I'd just like to keep things simple where possible
<birtles> If we can make an API where authors don't have to worry about the stacking behaviour if they don't need it
<birtles> it might be ok
<shans> me too, but I'm willing to sacrifice simplicity for power, and for fidelity
<shans> I think we definitely can. Authors will only look into the stack if they know they need to
<shans> oh btw, here's an additional use case that both you and I should cover in our proposals:
<cabanier> they should be able to just use style and not even know that they're dealing with stack
<shans> taking an existing transition and making it additive.
<birtles> ok, well, shall we leave the topic there for now and come back to it after I've put together an alternative?
<shans> sgtm - can you make sure your alternative also addresses that use case, and I'll do likewise?
<birtles> which use case?
<shans> taking an existing transition and making it additive.
<birtles> woah--how does that relate?
<birtles> isn't that something to address later when we look at additive animation?
<shans> well one of my claims is that the stackable approach makes this easier :-D
<birtles> (in all it's different flavours)
<shans> we don't need to address the result, just how an author could ensure that every time a particular transition runs it adds to (whatever that means) rather than replaces underlying behaviours
<birtles> feel free to outline how it might work, but I'd rather not integrate it just yet
<shans> ok
<shans> AnimationFunction has an attribute additive
<birtles> yeah, that was just copying stuff from SVG :)
<birtles> but I think we can do better than SVG
<shans> make sure your proposal addresses how a web author can ensure that for a particular specification of a transition, that value can be set for all elements that run that transition
<birtles> like some of your ideas about from() and to()
<birtles> "that value" ?
<shans> it's an example of being able to use code to modify all the instances of a transition
<shans> the attribute additive value
<shans> or make one up
<shans> attribute sparkly
<shans> whatever
<birtles> yeah, it's called CSSStyleDeclaration :)
<shans> no, it isn't
<shans> you can't currently specify that in CSS
<birtles> oh, ok, gotcha
<shans> :)
<birtles> yeah, ok, I think I addressed that
<shans> great
<birtles> alright, next topic
<birtles> we have synchronisation discussion and accessibility
<birtles> ok to do sychronisation now?
<cabanier> yes
<shans> sure
<shans> we mightn't finish but we can start?
<birtles> yeah
<birtles> http://www.w3.org/Graphics/fx/wiki/Synchronization_Approaches_Discussion
<birtles> I had three really quick points to make on that
<birtles> 1) I'd like to take an action to investigate the feasibility of Rik's proposal wrt to the DOM event model
<birtles> I expressed some concern about it not scaling, so I'd like to ask some folks here about how they think it might work
<shans> sounds like an important consideration
<shans> I'm also a bit worried about pausing on events
<birtles> 2) I wonder if we need to start talking about how synchronisation should work in general and then come back to the issue about integration with script
<cabanier> for the event firing, it would be similar to onanimation event (or whatever it's called)
<birtles> 3) In the Metro example, I wonder why you're using script at all?
<cabanier> RequestAnimationFrame
<cabanier> 3) correct, there should be no script
<shans> wait, what's the Metro example?
<cabanier> http://mobiletest.host.adobe.com/w3c/Metro.html
<birtles> So, on (1), the concern is just that I don't know how well the pausing behaviour would work inside the DOM event model
<birtles> so is it ok for me to take an action to investigate that?
<cabanier> yes
<cabanier> it would be a 'special' event. In the flash model, they aren't even considered events
<shans> we have some people working on a new DOM event model in the US too. I could talk to them if you want, depending on the outcome of your discussions?
<cabanier> since they're synchronous.
<birtles> shans, that would be great!
<cabanier> also ask how RequestAnimationFrame works
<birtles> cabanier, ok, will do
<birtles> skipping (2) just temporarily, with (3), the example currently uses script right? why is that?
<shans> someone behind me knows RAF pretty well
<cabanier> 3) because you can't express it in css
<shans> basically it's a call from the browser into JS when the next frame is ready to be rendered, and (as with all calls into JS) the world pauses until the function returns
<shans> (I just asked them)
<cabanier> well, for this simple example you could, but not when it gets more complicated ie the dog's head has animations
<cabanier> or is reused in other parts of the animation
<birtles> ok, fair enough
<shans> hey O
<shans> erk
<shans> I'm really sorry about this - I need to duck across to tech stop for a couple of minutes before they all run away for lunch
<cabanier> erk? :-)
<shans> mistype
<birtles> so if we increase the power of declarative animations there should be less need to these synchronous event handlers, but they won't go away entirely
<birtles> sure!
<shans> brb
<birtles> how's your time Rik?
<birtles> do you need to go soon?
<cabanier> brian, yes. there should be very few of those
<cabanier> no, I'm good
<cabanier> if there are many callbacks, you can expect performance to suffer
<birtles> yeah, ok, well that ties into (2) a bit so maybe we should wait for Shane
<cabanier> OK
<shans> back, sorry
<birtles> wow, that was fast!
<shans> they're provisioning a new laptop for me
<shans> I just needed to go and log in to trigger the next step
<birtles> SSD?
<shans> (my old one doesn't boot any more :-))
<shans> yeah I think it is. It's an air.
<birtles> oooh
<cabanier> HD are so unreliable these days
<birtles> SSD makes such a big difference
<shans> so I have a comment about the discussion wrt (3)
<birtles> yep
<shans> A while back Rik provided an example of a common approach in flash
<shans> the sunrise example. Do you remember it?
<cabanier> yes
<birtles> vaguely
<birtles> the next stage of the animation depends on the time of day
<shans> yes
<cabanier> moon from 0-5s, transition from 5-10, sun from 110-15
<cabanier> callback at 5s rewinds before sunrise
<shans> but it's default-on, so the script is required to execute in order to prevent the transition from occurring.
<birtles> so you don't want to start the next stage until the event handler has run
<shans> yeah
<cabanier> correct
<shans> so the comment I want to make is that if we continue to allow this as a commonly used technique, there will be a number of these pause-the-world callbacks required.
<cabanier> yes
<shans> which could hurt performance
<cabanier> that is why I proposed the animation-group idiom
<birtles> yeah, localise the damage
<cabanier> only the animations in the group will stop
<shans> ok, but that causes knock-on effects - you can't modify animations outside your group, for example
<shans> which I think is undesirable too
<cabanier> for instance if there are clouds floating by, you don't care if they don't line up
<cabanier> you still can, you just can't be sure of their state (which is how it is today in css)
<shans> also, does this mean you can't rely on time being constant between animation groups?
<shans> because I think that's bad
<cabanier> sometimes that's ok
<shans> it means you can't use animation groups as a structuring tool
<birtles> hang on, time is constant right? since it does the catch up after the handler has finished?
<cabanier> that is true
<shans> well if that's the case, then you can have weird artifacts
<shans> where two paths are supposed to meet but they don't because one is paused then catches up
<cabanier> but it might be running while you're in your handler
<cabanier> that's the metro example
<birtles> it means you get stuttering in part of your animation but not another
<shans> yes
<shans> which could break an animation invariant
<shans> (e.g. the head is attached to the body)
<cabanier> yeah, so for the parts of the animation you care about, you group
<cabanier> otherwise not.
<birtles> I think they are things you can work around, but I'm interested in the point I think you started to raise about whether we want to promote this approach
<shans> so for a complex figure
<shans> every part of the figure must be in the same group
<shans> which leads back to the same performance problem, right?
<cabanier> if you do everything and you have multiple disjoint animations on the page, you would force them to be all in sync
<cabanier> which seems expensive
<shans> and you can't group groups, as far as I can tell
<cabanier> why would it be a performance problem?
<shans> which means that animation groups can *only* be used to alleviate synchronization issues (at the cost of performance)
<cabanier> shane, correct
<cabanier> yes, that is their primary function
<shans> well, let's say you have a complex character animation, with each segment between joints animated. So 4 arm segments, 4 leg segments, the body, a few for the head, 20 or so for the fingers, etc.
<shans> each one is running independently using the sunrise pattern you've identified
<cabanier> no grouping?
<shans> but each interruption has to pause all the animations in the character, because otherwise things could appear detached
<shans> well there could also be grouping, but it doesn't change the point, I think
<cabanier> if they're grouped, they would all pause if there is a callback
<shans> yes, but that's the point. They all have to pause every time any of them calls back
<cabanier> if not grouped, they would appear detached for a short while
<shans> and if the callbacks are on different timers, that could be a lot of different times
<cabanier> people tend to not write too many script deep inside animations
<cabanier> so it doesn't become a problem
<birtles> Rik, how common is this? If CSS had declarative synchronisation of some sort would this sort of use be rare?
<birtles> If it's rare, maybe we don't need to go to the trouble of defining a new kind of event behaviour?
<shans> so let's say it's a dancing character. And you want to be able to independently change parts of the dance - i.e. now *this* arm is doing a different model
<shans> would you not use the sunrise pattern for this?
<cabanier> yes
<cabanier> but you would call the callback that often
<shans> ok, so now we have maybe 30 independent uses of the sunrise pattern?
<cabanier> would NOT
<shans> but all within the same animation group?
<cabanier> well, there would be only 1
<cabanier> but there are many subanimations
<cabanier> o, I see what you're saying.
<cabanier> like I said, people tend not to write complex scripts inside subanimations
<shans> hmm
<shans> this actually sounds like we're pushing complexity on people though.
<cabanier> so in the case the arms and legs would be animated differently
<cabanier> how so?
<cabanier> o, about the grouping?
<shans> actually can you finish what you were about to say? I think it directly relates :)
<birtles> yeah, I'm a little concerned about the grouping, especially if we *also* have time containers--if we get rid of groups or can align them with time containers somehow I don't think it's so complex
<cabanier> so, for your dancing charactor, the main timeline (or the timeline of the characters) would have a script that woud change the arms and legs
<cabanier> otherwise you'd need seperate scripts for arms and legs and have them talk to each other
<cabanier> I wouldn't be opposed to getting rid of groups
<cabanier> if people think it doesn't help much
<shans> no, I think groups are important
<birtles> :)
<shans> it's the pausing that I'm worried about
<cabanier> I was just worried that other parts of the page could suffer from one complex animation
<cabanier> well, we pause in flash and it seems to work OK
<cabanier> having many callbacks is bad so we tell people not to do that
<cabanier> having declararive animation is always preferred
<birtles> so we know pausing works ok for Flash, the question then is, does it work in a regular Web page?
<shans> I think the issue is that there's often a larger gap between event generation and javascript callback on the Web (when compared to Flash)
<birtles> i.e. with the existing DOM event model, and when you have many other events to compete with
<birtles> right
<cabanier> not with RequestAnimationFrame
<birtles> that's what I'm concerned about too
<shans> even with RequestAnimationFrame, I think?
<cabanier> it would be the same model
<cabanier> I don't believe that is the case
<cabanier> (I have to go in a couple of minutes...)
<birtles> ok, so I think we need to do some more investigation here
<shans> basically, you call requestAnimationFrame from javascript, with a callback that should be called *just before the next frame*
<birtles> Shane and I will look into it
<cabanier> OK!
<shans> yeah
<birtles> alright, so stuff for next time:
<birtles> * continuing this discussion
<birtles> * object primitives
<birtles> * accessibility
<shans> sounds good
<birtles> * synchronisation -- my suggestion that we need to take a step back and start designing declarative synchronisation in general
<birtles> anything else?
<shans> I'd like to discuss our time line - what we want to have done by when
<cabanier> sounds good
<shans> to get a handle on what we want to have ready by our face-to-face
<birtles> ok, sounds good
<birtles> * timeline
<shans> (I suspect some of the discussions we're having now will need to be delayed until then, is why)
<cabanier> we should start with that
<birtles> I'll make up an agenda page with those items
<birtles> first item, project timeline
<cabanier> when will we meet again?
<birtles> feel free to edit any of the wiki pages by the way, including the agenda pages
<birtles> I can do Fri/Thurs but is that too soon?
<birtles> Mon/Tues might be better?
<shans> I woudln't mind doing fri/thu
<cabanier> yes, let's go for that
<shans> keep the synchronization discussion fresh in our heads
<birtles> ok, so 24th for Shane and I, 23rd for Rik, right ?
<birtles> same time?
<shans> sounds good
<cabanier> OK
<birtles> great, thanks guys!
<cabanier> see you then!
<birtles> see you!
<cabanier> yes, thanks!
</pre>