Web Animations/Meetings/Meeting 3

From Effects Task Force

Time, location: 9 Feb 16:00 PST / 10 Feb 11:00 AEDT / 10 Feb 09:00 JST, #webanimations


  1. Meeting in Tokyo
  2. Rik's animation use case
  3. Prioritisation
  4. Object primitives


<birtles> hi Shane and Rik, are you free to meet?
<shans> yep
<cabanier> hi. I'm here
<birtles> ok great
<birtles> so for the agenda I have:
<birtles> 1) Rik's animation group use case (synchronisation behaviour)
<birtles> 2) Prioritisation
<birtles> 3) Object primitives
<birtles> is there anything else to add?
<shans> is 3) an API proposal?
<birtles> yeah, that's right
<shans> great :)
<birtles> just some very preliminary thoughts, don't expect much :)
<shans> then .. nothing further, y'honour
<birtles> :)
<birtles> well, in that case shall we start with Rik's mail?
<cabanier> there was talk about a get-together in Tokyo?
<birtles> right, are you able to come?/interested in coming?
<shans> oh yeah we should definitely discuss that too
<shans> is that item 0) then?
<cabanier> I believe so
<cabanier> hehe
<cabanier> I haven't talked to vincent, but I should be able to come
<shans> awesome
<birtles> unfortunately, no else is here at the office yet so I can't confirm my availability for March but I think the dates I sent to you Shane are probably roughly correct
<birtles> so was it mid-March we were thinking about?
<shans> mid-late march
<shans> so these dates are OUT: 24 Mar-1 Apr, and 7 Apr-16 Apr
<birtles> and I think you were busy, Shane, during early April so 1-7 Apr is also probably out right?
<shans> I don't know exact dates yet but let's avoid those if possible
<cabanier> for me: 5-9 are out as well as 15-20
<birtles> for March?
<shans> both March?
<cabanier> yes
<shans> ok, so that leaves roughly 10-14
<shans> or 21-23
<shans> or maybe april 2-6 ish
<cabanier> well, it takes me a day to get there 
<shans> right, which means that probably 11-13 is the only viable option in March?
<birtles> probably best
<cabanier> 11-13 or 21-23
<cabanier> 3 full days should be enough, right?
<birtles> plenty I think
<shans> definitely
<shans> if 21-23 could work that would suit me better
<birtles> ok, I'll try to confirm today
<cabanier> was Alex joining too?
<birtles> I'll be a bit busy then, and there's a small chance I'll be unavailable on 23rd
<shans> I think Alex is interested in joining in if everyone is happy for him to
<birtles> fine with me
<birtles> 11-13 is better for me, but 21-23 is not impossible
<cabanier> yes.
<shans> ok, let me check 11-13 then
<shans> it's probably OK
<birtles> ok great, thanks
<birtles> I can commit to 11-13 now, but 21-23 I have to check
<birtles> as for venue, we have some meeting rooms here we can use I think
<birtles> we're pretty small though (Mozilla Japan)
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<shans> cabanier needs a new chat client :-D
<birtles> totally :)
-->| cabanier (cabanier@ has joined #webanimations
<birtles> wb
<birtles> I need to check about the rooms
<cabanier> did I miss something?
<shans> nope :)
<shans> I can very likely do 11-13
<shans> I would like to chat with my wife to make sure, but I can let you know early next week
<shans> so let's lock it in for those dates, at least provisionally
<birtles> ok great
<cabanier> ok
<birtles> alright, done
<cabanier> on to topic 1...
<birtles> yep, thanks for the mail Rik
<birtles> I agree time containers don't solve that problem
<cabanier> it was just a quick brain dump.
<birtles> but I think you can already solve that problem with SVG
<birtles> it's just not implemented properly in most user agents I suspect
<birtles> (including Gecko sadly)
<cabanier> if so, can you point me to where that is defined?
<birtles> I'll explain how I think you can do it and you can let me know if I've understood the problem correctly
<cabanier> ok
<birtles> at t=5s an animation ends and an end event is dispatched
<birtles> in that end event, the timestamp *should* be set to t=5s
<birtles> this is the part that isn't currently implemented in Gecko
<birtles> I'll find the link in SMIL that describes this
<birtles> at t=5.5s the event actually is received by JS
<cabanier> correct
<birtles> the script creates the new element or whatever it wants to do
<birtles> it sets up a new animation
<birtles> and it sets the attribute begin="5s" by reading the timestamp from the event
<birtles> then when the script execution block exits the animation will begin
<birtles> the time now is about t=6s
<birtles> but the animation will play as if it started at t=5s
<birtles> i.e. it will be fast forwarded 1s
<cabanier> yes. other parts that were still running are no longer lined up
<birtles> why not?
<shans> wait
<shans> birtles is talking about how it *should* be
<shans> and from his description, everything *will* line up
<birtles> right, they *should* line up, but currently they won't due to quality of implementation issues, not spec issues
<shans> also, for the record, that to me sounds like how time containers should work
<shans> i.e. if stuff is in the same time container then it runs according to the same clock, regardless of whether or not the 'start' time is before the current time when an animation is added
<cabanier> if it's all declarative, yes
<cabanier> but there's nothing about what happens with js
<birtles> I think Rik's particular issue is about the integration with JS
<shans> ok
<shans> so our animation objects must have an option for setting the start time
<shans> (which, if not set, defaults to 'now')
<birtles> one problem is we have stuff like beginElement() which will start at the current time (as returned by getCurrentTime())
<birtles> but at least in Opera, you can get ticks taking place within a script block
<birtles> so you can call getCurrentTime() followed by beginElement() and they won't necessarily match
<birtles> in Gecko they will
<birtles> but I'm pretty sure it's not guaranteed in Opera
<cabanier> also, what state is the animation in during the callback.
<cabanier> Everything should be as if the time offset = 5s, not 5.5s
<birtles> but if you use begin="5s" etc, you can get around that
<shans> what does beginElement do sorry?
<birtles> cabanier, I think that's a tall order
<shans> you actually really want time to continue to flow during script execution btw, otherwise disparate timelines don't line up
<birtles> yeah, they'll all running off the same clock
<birtles> they still line up, you just don't get animation ticks
<birtles> it's the same as requestAnimationFrame
<birtles> cabanier, maybe I need to think about that more
<cabanier> OK
<birtles> cabanier, perhaps using a mechanism other than events is a better way to go
<birtles> or another kind of event
<shans> woah, why is it called beginElement then?
<cabanier> yes, they're not really like regular event
<birtles> beginElement adds an instance time to the list of begin times
<shans> oh right, I see
<shans> so you can't beginElement multiple elements and have them start in sync, because time can elapse between them
<birtles> in Opera, that's right
<shans> otoh can you specify a time when calling beginElement?
<birtles> beginElement = beginElementAt(0)
<birtles> it's relevant to the current time
<birtles> as returned by getCurrentTime
<shans> so you could do
<shans> t = getCurrentTime()
<shans> for (element in elements) {
<shans> ah no
<shans> relative
<shans> dammit
<shans> there's no way to set an absolute time?
<birtles> yeah, I think we want an interface where you can specify absolute times
<birtles> other than setAttribute("begin", "5s")
<shans> definitely. I think having something like that as the default, and building relative time wrappers for convenience is the way to go
<birtles> I agree
<birtles> where absolute time = time container time
<shans> yeah
<shans> but time container times are related to each other by fixed offsets
<birtles> so I think for Rik's use case, at least two things are needed:
<shans> so time container time = absolute time wi�th specified '0'
<birtles> 1) animation events to embed the time when they were generated (in document time probably?)
<birtles> 2) a method of triggering animations using absolute times
<shans> yes, I think that's right
<shans> Rik, what do you think?
<birtles> and optionally, 3) a new kind of event generation that pauses animations in the container
<cabanier> why would I want to know when an event was generated?
<birtles> (when the event is generated)--script handlers then have to unpause it
<shans> I think 3) is going to lead to synchronization issues
<shans> I would argue against it pretty strongly
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<birtles> yeah, ok
<shans> wait for Rik :)
<birtles> oh yeah,
<birtles> I've started ignoring those messages :(
-->| cabanier (cabanier@ has joined #webanimations
<cabanier> 3 is needed to fix synchronization issues
<shans> no, I don't think so
<shans> here's how I think about things
<shans> there's a real, global time
<cabanier> what if you swap an animation out with another one (=change the time container)?
<shans> it doesn't stop
<shans> maybe we have a concept of local time (time containers)
<cabanier> OK
<shans> but they're fixed to global time, one to one
<shans> essentially they're just a translocated 0 point
<shans> if you genuinely want strongly aligned control of animations, time can't stop anywhere
<birtles> right
<shans> although it might seem convenient to stop time container time so that things start at the same time, this destroys the alignment of the time container with global time
<shans> it means you can never split animations across time containers without losing sync
<shans> so instead, you need to be able to refer to absolute positions in global time
<shans> "this animation starts at 5s" (OK, it's 6 seconds now, so I've missed a few frames, but I know that I need to present a frame 1s into the animation next)
<birtles> maybe part of the confusion here is that CSS Animations doesn't have this concept of global time
<shans> it's analogous to what happens when the frame rate drops - you get stuttering, but the animation itself keeps the correct time
<birtles> right
<shans> birtles yeah I think that is very likely true
<birtles> I mean it doesn't have that concept yet :)
<shans> :)
<shans> Rik - am I missing something though?
<cabanier> part of my proposal was : When resuming, the browser is expected to fast forward the stopped animation to make up for the lost time.
<shans> aaaaaah
<cabanier> which is the stuttering
<shans> got it
<shans> so the "script time" is just the current paused time, and it's brought back into alignment as soon as the script ends
<cabanier> correct
<shans> and this is a convenience to make it easier to align multiple animations
<shans> I like it :)
<birtles> btw, when I was talking about not getting ticks before I wasn't talking about stopping time--time still advances but within a script block we'll return the same value for getCurrentTime
<cabanier> if there are other events that happened during that time, they are expected to execute too
<shans> ok
<shans> now I understand what's going on
<cabanier> this is basically the flash model
<shans> we could do a lot worse than attempt to emulate the flash model. It's been very successful for animation
<cabanier> and it allows your graphics to be in perfect sync with audio, video 
<cabanier> no matter how many scripts you execute
<shans> yeah, now that I get what you're proposing I like it a lot. What do you think Brian?
<birtles> I'm not sure
<birtles> how is it different to what I suggested before--i.e. when dispatching the event, pause the animation?
<shans> I think it's the same, or nearly
<cabanier> the fast-forwarding is the other part
<shans> we don't actually need to pause the running animations though, just not deliver time updates to the script
<cabanier> I believe they need to be
<cabanier> otherwise your script might try to change content that is no longer on the stage
<shans> hmm
<birtles> so if I can clarify one approach, basically these events get told "getCurrentTime() = 5s" even though it's not, and all operations they execute behave as if getCurrentTime() = 5s. Of course the current time is actually 6s and so when the animation takes effect it will be fast-forwarded as per SMIL's usual frame-rate agnostic behaviour
<shans> yeah I can see that
<birtles> but other other approach is just to pause on dispatch
<birtles> then the question is what to pause and Rik suggested using animation groups for that
<birtles> is that what Flash does?
<shans> the first approach is what Rik's suggesting. I *thought* he was suggesting the second approach. Which one did you have in mind Brian?
<cabanier> what is getcurrrenttime? does it return an absolute time or the time of the container?
<birtles> currently they're the same thing
<birtles> if we introduce time containers it would depend on where you called it
<birtles> in my example, I was thinking of absolute document time
<cabanier> ah. yes, that one should not return the past time
<birtles> so if I understand correctly, Rik is basically suggesting pause on dispatch, but pause the animation group
<birtles> oh no, that's not right
<birtles> because then you won't get the fast forward behaviour
<cabanier> birtles: a Flash movie acts like a single anaimation group
<birtles> so how do you avoid freezing the animation whilst you wait for event handlers to execute?
<cabanier> you don't. the animation group is frozen until they return
<cabanier> and then fast forwarded
<birtles> and that doesn't lead to jank?
<shans> does that mean you can only access information in the animation group from an animation group event handler?
<shans> i.e. you can't get at any of the other animations groups?
<cabanier> if your script is complex, yes. so don't do that :-)
<cabanier> shans: I have to think about that...
<birtles> I wonder how it scales in a Web context when you can have many event handlers queued
<birtles> also, we currently dispatch the event even if no-one is listening
<cabanier> no, you can. but you should rely on them
<birtles> maybe that's a quality of implementation issue though
<shans> hey
<cabanier> yes, as you said before, it's not really an event
<shans> what if an animation group's set of animations is viewed as a timeline with a play cursor and an edit cursor
<shans> normally the edit cursor tracks the play cursor
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<shans> ... :)
-->| cabanier (cabanier@ has joined #webanimations
<shans> but when an event handler is called, the edit cursor is frozen
<cabanier> I missed part, sorry
<shans> normally the edit cursor tracks the play cursor
<shans> but when an event handler is called, the edit cursor is frozen
<shans> (that was all)
<shans> modifications to the timeline inside the event handler occur at the edit cursor
<birtles> hmmm... might be do-able
<birtles> internally, you'd do a seek backwards, run the script, then do a forward seek
<shans> looking at things in this way removes issues about things disappearing from the stage, I think, because animations don't remove themselves from the timeline on completion
<shans> nah not even
<shans> you'd represent the timeline as a series of occurrences sorted by time
<shans> then fast-forward from the edit head through the occurrences to generate additional events
<shans> until it caught up with play time
<birtles> that's the same thing isn't it?
<shans> pretty much :)
<birtles> that's how we currently do forward seeks
<birtles> backward seeks are expensive though
<birtles> but probably still cheap enough
<shans> also you could modify other animation groups too - any modification would freeze the edit head for that group (and you could then seek it as necessary)
<shans> why are backward seeks expensive?
<birtles> because you basically throw away all the intervals and recreate them
<birtles> otherwise you need to keep a log of all intervals that ever fired
<birtles> and that just means you leak memory
<shans> we shouldn't actually need to do a backward seek anyway - freezing the edit head does nothing except set a time reference. Modifying the timeline will introduce extra animations but the events for those don't need to be generated until the script is over
<birtles> or you have to navigate syncbase dependencies in reverse which is really hard
<birtles> but before you run the script you need to do the backwards seek so you have the right animations active
<shans> no, I don't think so
<cabanier> so, in the handler, you would reverse the cursor to the edit position?
<birtles> because inbetween generating the event and running the event handler all sorts of syncbase dependencies could have fired
<birtles> and you need to undo all of them
<birtles> to get back to the state at that time
<cabanier> they might display something you don't want
<birtles> hence the pause behaviour
<shans> think about it this way - there's a single representation of the timeline, mutable only via script
<birtles> but it's not
<shans> in the absence of script calls, this representation completely specifies everything that happens in an animation
<birtles> it's mutable via syncbase dependencies
<shans> hmm
<shans> I'm not sure what you mean by that, I probably need to do more reading :)
<birtles> they generate new intervals which you can't calculate all of up front because you can have generative syncbase dependencies
<birtles> (i.e. cycles that keep producing more intervals indefinitely)
<shans> that's actually not a problem
<shans> it just means you need two representations
<cabanier> are those nested animation?
<birtles> no, they can be siblings
<birtles> I'm not saying either approach is impossible, just that the way we do backwards seeks is a bit expensive
<birtles> but it might not be prohibitive of doing the edit cursor approach
<birtles> the most expensive thing is still rendering
<shans> what if there's a reasonable-sized cache of the unpacked representation (the intervals data)
<shans> that would make backwards seeking a lot cheaper right?
<birtles> yeah, we keep a few around, but the complexity of navigating syncbase dependencies backwards worries me, especially when it comes to detecting and breaking cycles in a consistent fashion
<birtles> (this is one of the most interoperable areas of SVG animations---cycle detection)
<cabanier> ie if you have an animation that shows the moon for 4s, then shows a transition from moon to sun for 1s, and then show the sun. Also there is a script that is supposed to fire at 4s, looks at the time of day and if it's before 6am, it rewinds the animation. However, it fires at 5s.
<shans> ok, so given the possibility of caches: we know when we freeze the edit cursor that we'll need data from there forward. At the point we freeze it, the edit cursor is tracking the time cursor so we *definitely* have unpacked interval data. We just ensure that the cache keeps the data around until the edit head fast forwards again, and remove the problem of backwards seeking.
<cabanier> With the edit/play cursor, will you see the transition?
<birtles> shans, that's good
<shans> cabanier: yes.
<birtles> cabanier, good point
<cabanier> that's wrong...
<shans> cabanier: it means that you need to do things differently in this model.
<shans> cabanier: for eample, fire the script at 4s and if it's *after* 6am insert the transition
<shans> (or fire at 3s ;-))
<shans> I mean, it
<shans> erk
<birtles> (shans, I have to think about it more though---part of the trouble is not just getting the right intervals but having the right state in terms of dependency links)
<cabanier> people do this stuff for character animation in games all the time
<shans> it's worth pointing out that in the pause model this is wrong too, as the transition won't display if it's after 6am, because everything is paused :)
<cabanier> but that's good!
<shans> cabanier: oh?
<birtles> yeah, it's pausing, but not as you know it (pausing + catch-up)
<shans> but the transition won't display
<cabanier> that's ok
<shans> because by the time we get a chance to render again, we're past the 1s point
<cabanier> it will still be synced with the other animations
<cabanier> ie if you have a clock that is starts ticking when the sun's there
<cabanier> or when the transition happens
<shans> let me try to break this down a bit further
<shans> this example (which I'll accept people do all the time) is a case of scripting a state change but then preventing the change from occurring by rewinding until you need it to.
<cabanier> I actually have to leave in a couple of minutes....
<cabanier> correct
<shans> would it not make more sense to either have a state-machine based abstraction (;-))
<shans> or script the state change when it's actually required?
<shans> anyway, we can talk more next time maybe? Or if you want I could try to write something up for the next meeting so we've got a discussion point?
<cabanier> it all depends
<cabanier> the moon animation could transition gracefully into the sun animation
<cabanier> yes, that sounds good.
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<birtles> he wasn't joking when he said a couple of minutes :)
-->| cabanier (cabanier@ has joined #webanimations
<cabanier> 'll read up on syncbase
<shans> OK, I'll try to write this up today
<shans> and email it around
<birtles> thanks Shane!
<shans> Brian, I'm really sorry we didn't get to your proposed API :(
<shans> could you send it around too?
<cabanier> thanks!
<birtles> it's just some initial thoughts: http://www.w3.org/Graphics/fx/wiki/Web_Animations/API_Primitives
<shans> awesome, thanks! :)
<shans> can we meet again on Tuesday btw?
<birtles> suits me
<shans> (is that Wed or Mon in Europe?)
<birtles> Europe?
<cabanier> Mon in the US :-)
<shans> er, US
<shans> sorry :)
<cabanier> I will be there
<birtles> great, thanks so much guys!
<shans> thanks Brian
<cabanier> bye!
<birtles> (fwiw, Flash-style animations is something I'd love to see possible with the Web platform so I'm really glad we're having this conversation)
<shans> yay, me too :)
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@ has joined #webanimations
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@ has joined #webanimations
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@ has joined #webanimations
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@ has joined #webanimations
<shans> birtles: if you have a bit of time free, could you check out http://www.w3.org/Graphics/fx/wiki/ACTA:_Analysis_of_Missing_Features and see if it makes sense? This is the analysis of what features we'd need to provide in the web platform to support state-machine based animation in JavaScript
<shans> I'm going to start working on the other thing now :)
<birtles> shans, thanks mate! Will look at it after lunch
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@ has joined #webanimations
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@ has joined #webanimations
<shans> birtles: what happens in SVG if there's an animation triggered to start on click, and you click, let the animation run, then rewind to (a) just before the time that the click was registered or (b) just after the time that the click was registered?
<birtles> shans, sorry, back now
<birtles> (a) just before the click, the click is lost
<birtles> (b) just after the click, it's still there
<shans> birtles: hmm, righto
<birtles> let me find the reference for it
<shans> so a timeline in svg has divergent realities ;-)
<birtles> yeah :)
<birtles> basically, what we do is we keep a record of those event times and don't clear them (unless we reach some maximum)
<birtles> but for times generated by syncbase we drop them, because we can recreate them
<shans> but then discard the ones after a seek point
<birtles> right, when we do a backwards seek we drop all the times except the event ones (including DOM calls to beginElement)
<birtles> then we fast forward through the time graph to the seek time
<birtles> and then drop all the times after that point
<birtles> it kind of falls out of the reset behaviour and the hyperlink behaviour funnily enough
<birtles> (the backwards seeking behaviour is defined in the hyperlinking section)
<birtles> just let me pull up the references
<shans> sure
<birtles> the backwards seeking behaviour is here: http://www.w3.org/TR/SMIL/smil-timing.html#q114
<birtles> but you have to combine that with restart behaviour: http://www.w3.org/TR/SMIL/smil-timing.html#q44
<birtles> After you do the seek, you have "Any instance times associated with past Event-values, Repeat-values, Accesskey-values or added via DOM method calls are removed from the dependent begin and end instance times lists. In effect, all events and DOM methods calls in the past are cleared" where past means real-world time, not document time
<birtles> I seem to remember sending a few messages to www-smil to clarify this
<shans> righto
<shans> is there any particular reason for this behavior being more desirable than keeping a single view of the timeline?
<shans> like, does this allow a bunch of stuff that wouldn't work without it?
<birtles> you mean, for example, NOT dropping click events?
<shans> yeah
<birtles> I think it comes out of the fact that SMIL combines an event-based model with a scheduling model
<birtles> the event-based part kind of makes more sense if stuff remains interactive
<birtles> if you have a scene that plays with a few interactive elements if you mouse over or click them
<birtles> it's kind of unexpected that if you rewind the scene those things just move on their own
<shans> but that happens, right?
<shans> if you rewind the scene to just after a click, for example
<birtles> yeah, but I think that's still what you'd expect
<shans> which "you" are we talking about here? developer or user?
<birtles> user
<shans> ok. I agree with the first statement (it's unexpected that after rewinding the scene things move on their own)
<birtles> if you tickle a monkey and he laughs for 10s and mid-way you do a 0.5s backwards seek, I don't think you expect him to stop laughing
<shans> but I can't see the distinction with rewinding before and after the start of an event 
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<shans> hmm, I think that's conflating 2 different expectations
<shans> so in the first case, you assume the user expects the interactive elements to be unrecorded
<shans> but in the second case, you assume the user expects the interactive elements to be preserved
<birtles> the interaction is triggering the animation
<birtles> if you go to a time when the triggering has happened, it's happened
<shans> if you tickle a monkey and he laughs for 10s, and you mouseOver a clock and it ticks for 5s, and you seek back 6s, why has the mouse stopped while the monkey's continued to laugh?
-->| cabanier (cabanier@ has joined #webanimations
<birtles> the mouse?
<shans> at any rate, these decisions are based on expectations of the user / developer, not because there's a devestating loss of features if you don't do it this way?
<shans> er sorry, the clock
<birtles> there's all DOM calls
<birtles> s/all/also/
<shans> right, I wasn't sure about what that meant
<birtles> it means beginElement(), endElement() etc.
<shans> so if I add an animation to the DOM via createElement / appendChild for example
<shans> ohhh
<shans> ok
<shans> custom triggers, basically
<birtles> yeah, perhaps scripted and based on the current time
<shans> yep
<shans> and they get removed as well
<birtles> I think you'd want their results to be cleared so you don't get double-triggering
<shans> because the same scripts might fire again under the same conditions
<birtles> yeah
<shans> then again, if that were the case, shouldn't that stuff be programmed declaratively rather than on scripts/
<birtles> well, even if it's just an endEvent handler
<birtles> that conditionally triggers an animation
<shans> e.g. for chaining animations/
<birtles> based on some other conditions
<shans> oh hmm, yeah, conditionally could be an issue. Good point
<shans> ok, but in this kind of situation you could do a seek and then manually request the timeline to be pruned back to some initial condition
<birtles> hmm, I gotta think more about the seeking behaviour--it seems natural to me, there must be a real-world parallel
<birtles> it's like a time machine :)
<shans> well the thing about time machines is they're paradoxical :-D
<birtles> if you go back in time, you can't change what happened before that time (what ever events were set into motion) but you can change what happens after :)
<shans> yeah, I can see the parallels
<shans> just not sure if this is the simplest model, either from the perspective of describing what happens on seek, or from the perspective of implementing
<shans> I think a consistent timeline that is modified by scripts might be easier to think about
<birtles> yeah, ok
<shans> then something like onClick becomes a script-that-is-hardcoded
<shans> i.e. it acts like a script but no actual JavaScript needs to be written
<birtles> well, I don't know that this area is particularly consistently implemented so it might be something you can get away with changing
<shans> heh
<birtles> we spent a lot of time on it in Gecko but I don't think other implementations have
<shans> as long as SVG's behaviour can be modeled, it's ok
<shans> and I think it can be
<birtles> still, the model as it stands seems natural to me, but I can be persuaded otherwise
<shans> if you've got a 'default' timeline which doesn't include the interactive stuff, then you just manually strip out any interactive stuff after the cursor once you've seeked
<shans> I'm a lot closer to see how it can be considered natural now
<shans> s/see/seeing/
<shans> which is good :)
<birtles> yeah, basically
<birtles> it's a scheduling model + an event-based model
<birtles> you keep the scheduled part and strip out the event-based bit
<birtles> (with the exception of events in the past)
<shans> yeah
<birtles> maybe that last condition is the sticking point though
<shans> so the question I'm asking is should that behavior be specified, or should something simpler be specified and that behavior just be implementable on top
<birtles> I depends on what shape the API takes I guess
<shans> yep
<birtles> the minimal API I've put forward doesn't really have a scheduling component
<birtles> yet anyway
<shans> I quite like it so far btw
<shans> oh there was one thing which I think is wrong about CSS keyframes - just a minor thing
<birtles> you just generate events and assign them start times---it's SVG's job to turn begin="3s; 5s" into two animations at the right time
<birtles> yep?
<shans> I think it's wrong. I'm just going to check...
<birtles> it almost definitely is
<birtles> :)
<shans> ah. It's underspecified. What a surprise for CSS animations
<birtles> that might be to our advantage :)
<birtles> the more vague it is, the more wiggle room we've got
<birtles> to make something that's compatible
<shans> basically, I *think* that if you do something like @keyframes foo { 0% {  width: 100px; height: 100px; } 70% { height: 20px; } 100% { width: 0px; height: 100px; }}
<shans> then width interpolates from 0% to 100%
<shans> i.e. you can partially specify intermediate keyframes
<shans> but I'm not sure of that :)
<birtles> yeah, I wondered about that
<birtles> I really hope you *can* do that
<birtles> I'd much rather have an array of properties, each with their own set of frames (offsets and values)
<shans> yeah I quite liked that idea
<birtles> Than a sequences of frames, each of which specifies the value for each property
<shans> but of course the API representation and the CSS / SVG representations don't need to match, they just need to be equivalent
<birtles> right, so long as you can represent CSS that's enough
<birtles> but it's preferable for developers if they can switch between the two easily
<shans> definitely
<shans> did that other document make sense btw?
<birtles> sorry, there is a guy here installing a phone
<birtles> I'm 3/4 of the way through it
<birtles> so far, makes perfect sense
<shans> no worries
<shans> great
<birtles> still going but I read "the CSS declarative syntax were abandoned and state machines were only generated procedurally - this would remove the need to build up state machines from rules associated with selectors of various specificities."
<birtles> do you think an element syntax is more suited to this?
<birtles> is that another possibility? just put it in SVG assuming SVG can target style in HTML?
<shans> hmm
<shans> there are definitely additional challenges imposed by the selector syntax
<birtles> that's pretty much what we're doing with Filter Effects
<shans> I think I'll remain on the fence :-)
<shans> as in: I certainly wouldn't be upset if that was the direction we ended up going in
<birtles> ok
<shans> oh, actually, I added a final section to the proposal as well (about @node). That section kinda highlights some of the challenges of working in CSS land to me
<birtles> oh, I'm looking at the wrong doc I think
<birtles> just the missing features doc
<shans> yeah that's the one I wanted you to look at, but the new section is in the other doc
<birtles> ok, just can I check one thing with the missing features doc
<birtles> the two last points
<birtles> relative keyframes (from(), to(), prev() functions)
<birtles> animation blending
<shans> yep
<birtles> so "from()" is basically additive animation with the underlying style
<shans> hmm
<birtles> and "animation blending" is additive animation with other animations?
<shans> not exactly, in both cases
<shans> from() could be used to define an additive animation with the underlying style
<shans> if for example you did something like from: {width: from(); } to: {width: calc(from() + 100px); }
<shans> but actually from() just extracts the starting conditions, and to() extracts the end conditions
<birtles> how does to() work?
<birtles> oh, it's for transitions
<shans> hmm, yeah, to() mightn't make sense outside of the context of the proposal
<birtles> where you have an underlying change
<shans> yes, that's right
<shans> oh right! yeah - if there's no underlying change, to() == from()
<birtles> ok, that makes sense
<birtles> and prev() is relative to other keyframes
<shans> yep
<shans> I wanted a next() too, but that introduces loops :(
<shans> now, additive animation vs. animation blending
<birtles> yeah, I guess
<shans> additive animation, as far as I understand it, is trying to apply multiple different animations at the same time to an object
<shans> but animation blending is interpolation between animations 
<birtles> gotcha
<shans> basically an animation with animated end points :-)
<birtles> yep :)
<birtles> looks good Shane
<birtles> it sounds like we need a way of having animation values that are relative to:
<shans> great. So basically, yeah, we could get to a pretty happy place without encoding this stuff in the API
<birtles> a) the underlying style
<birtles> b) underlying animations
<birtles> c) previous intervals and keyframes
<birtles> d) other animations?
<shans> for some sense of the word relative, in each case, but yep
<birtles> yeah, SVG only lets you do some combinations of those---I think what you've suggested is more powerful in many ways
<birtles> for example, SVG lets you make all animation values add to underlying style/animations but you can have just the end point be relative
<birtles> (you can have just the start-point in the case of to-animation)
<birtles> but the from() syntax lets you make either end-point relative
<birtles> so there's probably some way to capture all those possibilities in a generic fashion
<shans> I think so, yeah
<shans> I really like this approach too, of refactoring the use cases back into features as high as possible up the tree
<shans> not tree
<shans> up the specification stack
<shans> I think we'll end up with something pretty small and neat
<birtles> I hope so :)
<birtles> have you met Dmitri who made Raphael?
<shans> not face-to-face, but I've been to one of his talks
<birtles> it might be worth talking to him to see what he'd like to see in an API
<shans> great idea
<birtles> to help us work out what should be in the API and what we can do in SVG/CSS
<birtles> http://dmitry.baranovskiy.com/ -- says he's at Digital Five
<birtles> can't work out where that is though, but I'm pretty sure he's still in Sydney
<shans> says he's Sydney based on that page
<birtles> right, yep, that would confirm it :)
<shans> I could drop him a line, see if he'll come have a chat
<shans> we should firm up our requirements list first I think
<birtles> that'd be great
<birtles> yeah, that's true, it can wait
<shans> ok, here's a start on the synchronization stuff
<shans> http://www.w3.org/Graphics/fx/wiki/Synchronization_Approaches_Discussion
<shans> very rough at the moment though
<shans> but it's time for me to head off :) I'll keep hacking away at it next week
<birtles> great, thanks Shane! have a good weekend!
<shans> cheers, you too