Web Animations/Meetings/Meeting 2

From Effects Task Force

Time, location: 6 Feb 16:00 PST / 7 Feb 11:00 AEDT / 7 Feb 09:00 JST, #webanimations

Log

<birtles> hi guys
<birtles> are you reading to start?
<cabanier> hi brian
<cabanier> not sure if Shane is here
<birtles> hi Rik!
<shans_> I'm here
<cabanier> great
<shans_> hi guys
<shans_> sorry, just working on what I said I'd have finished by this meeting :/
<birtles> ok, great!
<birtles> I updated the wiki: http://www.w3.org/Graphics/fx/wiki/Web_Animations
<birtles> I just put a lot more requirements in
<shans_> I saw that
<shans_> it's a big list :)
<birtles> yeah, I guess what I wanted to talk about today was how we attack things from here
<birtles> also, I just wanted to clarify where we stand with regards to SMIL
<shans_> you had a couple of agenda items from last week 
<shans_> yeah SMIL was one of those, right?
<birtles> but did you guys have other items you wanted to talk about?
<birtles> shans_, yeah, those were pretty much the two items
<shans_> heh
<shans_> I don't have anything I want to talk about, but I did put this on the wiki: http://www.w3.org/Graphics/fx/wiki/Advanced_CSS_Transitions_%26_Animations_Proposal
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<birtles> maybe a third item is feedback about the state machine proposal
<shans_> at the moment it's just the doc from last week
<shans_> yes, that'd be good
<birtles> ooh, nice
<birtles> Rik, did you get a chance to look at the proposal?
<shans_> oh, rik's disconnected
<shans_> :(
-->| cabanier (cabanier@192.150.22.150) has joined #webanimations
<birtles> oh yeah, I didn't notice
<shans_> there he is :)
<cabanier> man.
<cabanier> there's something wrong with my chat client
<cabanier> It keeps dropping
<shans_> cabanier: http://www.w3.org/Graphics/fx/wiki/Advanced_CSS_Transitions_%26_Animations_Proposal is the doc from last week. birtles has suggested we discuss feedback about it as a third agenda item.
<cabanier> I'll find another one
<cabanier> OK
<shans_> birtles: what do you want to start with then? SMIL?
<birtles> yeah, sorry about the delay, the cleaner here is very talkative :)
<shans_> haha :)
<shans_> np
<cabanier> \
<birtles> yeah, SMIL should be quick
<birtles> Vincent keen for us to build on SMIL's experience
<birtles> I'm inclined to agree somewhat---I don't want to define a whole new timing model from scratch and hope it works
<birtles> but there's a lot of stuff we don't want in SMIL (e.g. smilText), a lot of complexity we don't need
<cabanier> agreed
<birtles> also, a lot of people scoff when they hear the word SMIL because it's seen as complex and when IE did HTML+Time it didn't get much take up
<birtles> so I want to learn from SMIL but be careful about how we use it, adapt rather than adopt
<birtles> also, I want to avoid too much overt reference to SMIL
<shans_> yes, I think that's wise
<cabanier> yes
<shans_> maybe we should start talking about being "compatible with animation aspects of SMIL"
<cabanier> why even mention it?
<shans_> or that :)
<shans_> but if people ask
<birtles> right, ok, I think we're on the same page here
<birtles> I think I'd rather not mention it unless we have to
<shans_> same
<birtles> ok, item 2 then: how to proceed from here
<cabanier> your list is pretty large
<birtles> right, I guess the next step is triage then
<birtles> crossing out stuff we don't want and so on
<cabanier> or list in order of importance
<birtles> right
<birtles> also, it seems large but a lot of it is stuff we already have in SVG Animations / CSS Animations and therefore possibly need for backwards compatibility
<birtles> although we might decide, for example, that some features only belong in SVG and not in the API
<birtles> and we might deprecate others on the way (e.g. wallclock timing)
<birtles> so I started doing that already
<shans_> I think I prefer ordering by importance rather than removing stuff
<shans_> my gut feel is that we'll end up proposing a core model
<shans_> and at that point we can go back and see how much of the requirements list fits the model
<birtles> ok, sounds good
<birtles> I'd prefer the core model to be a little more requirements driven, but if it's an iterative process then maybe it doesn't make any difference where you start
<cabanier> Synchronisation should be core to the model
<shans_> oh, sorry, I don't disagree - we definitely want to be requirements driven
<shans_> what I mean is that we'll generate "core" requirements, build a core, then look at the leftover requirements and see what else fits
<birtles> gotcha
<birtles> ok, that's good
<birtles> yeah, synchronisation is important
<shans_> agreed
<birtles> well then, does someone want to add to the wiki their idea of priorities and we can then come back and discuss it?
<birtles> that might be more efficient than going through all of them now?
<cabanier> I think we can discuss it here.
<shans_> that sounds awesome
<shans_> oh
<shans_> that's good too :-)
<cabanier> I know what my priorities are but those do not necessarily correspond with yours
<birtles> well, how about Rik, can you give us your top 5 (or top 10) or whatever?
<birtles> since you have some solid use cases
<cabanier> 1. synchronisation. within groups/descedant animation
<cabanier> 2. synchronized javascript interfaces = a way to get around the asynchronous behavior of SMIL/CSS animation
<cabanier> 3. Better API
<cabanier> 's to control animations so you don't have to muck with CSS style names
<cabanier> 4. custom easing (not that important, nice to have)
<cabanier> These would be great for us and correspond to some of the items on your list
<birtles> ok, that's great
<birtles> I think those items are all enhancements over what's currently available in CSS Animations
<shans_> from our perspective: #1, #3 definitely
<shans_> #2 I don't understand
<shans_> #4 agree it's a nice-to-have
<shans_> plus I have a couple of priorities that I could add to that list
<shans_> (want them now?)
<birtles> yes, sure
<shans_> a. better  support for widget behaviors (this is basically some form of the proposal we've been working on) 
<shans_> b. better support for paths (actually this is something SVG has that CSS doesn't, so it'll probably end up in there anyway)
<cabanier> #2, if you have an animation of 2 objects and you want to switch out one of the objects with another object (using the animation-end event), there is no way to keep the 2 animations in sync
<shans_> cabanier: got it. We're interested in that too
<cabanier> is b the case where you want to define a motion path in CSS?
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<shans_> we'll wait for him to get back
-->| cabanier (cabanier@192.150.22.150) has joined #webanimations
<birtles> cabanier, could you explain that in a bit more detail in the wiki? maybe even with code examples? you could add a bullet point and a link to a sub-page
<shans_> cabanier: yep
<cabanier> I'm back  :-)
<cabanier> I will do so.
<birtles> re motion on a path, SVG WG already resolved to extend that to a more generic functional syntax
<birtles> so you can smoothly interpolate between pairs of values
<cabanier> b is something that we're working on as well with CSS exclusions.
<shans_> birtles: awesome
<shans_> birtles: I'm interested from the perspective of exposing these behaviors to CSS. I think SVG is doing a lot of the right stuff in this area
<birtles> yeah, by the way, I thought more about the API approach and I love it
<shans_> great! What do you think of it, Rik?
<birtles> I think it ties in well to Rik's requirement #3
<cabanier> the one we discussed last week? yes, that would be great
<birtles> as for my priorities, I'd love to see time containers (which might tie in to Rik's requirement #1)
<cabanier> element->animation.stop/start/gotopos
<birtles> also reversing, but CSS already has that so presumably we'll port that to SVG in the process
<birtles> (via the API)
<birtles> anyway, in terms of priorities
<birtles> a lot of the requirements I listed simply refer to features that are already available
<birtles> in SVG or CSS or both
<birtles> I'd like to just say "all those requirements are top priority, non-negotiable"
<birtles> but I don't know if we should
<birtles> since some of them we might not want
<shans_> well I get the sense that if we can't support the vast majority of existing behaviour in both SVG and CSS then we're sunk
<birtles> yeah, true
<shans_> BUT that doesn't mean that we need to default to those behaviours, if we're taking the API approach
<shans_> we just need to support them
<birtles> right, we still need to consider how to approach each one
<shans_> yeah
<birtles> i.e. do we just handle this in SVG using the features of the API, or do we build it into the API
<birtles> and in some cases, we might want to even say, "deprecate it, there's something better in the model for that now"
<shans_> right. And at the least we need to make sure that it's possible to handle in SVG/CSS using the features of the API
<birtles> but, nevertheless, it might be a useful first step (in terms of prioritisation) to split up the requirements into (a) existing functionality, (b) enhancements
<cabanier> and exisiting, is that what's in CSS now?
<shans_> sounds like a good idea
<shans_> what's in CSS and what's in SVG now
<cabanier> or do you inlcude SMIL?
<cabanier> ok
<birtles> cabanier, the union of CSS and SVG
<birtles> definitely not SMIL in the sense of SMIL 3.0 :)
<birtles> alright, well I'll rearrange the wiki accordingly
<birtles> I'll add the prioritisation we discussed before and we can refine it next time
<cabanier> I'll add my use-case for javascript synchronisation
<birtles> thanks
<shans_> should I add a widget animation use-case too?
<cabanier> yes
<birtles> yeah, thanks
<birtles> I added a use case section at the top, so maybe you can add it there?
<shans_> will do
<birtles> I think in parallel we can start to talk about the primitives of the API
<birtles> i.e. what do we want to model
<shans_> yep
<cabanier> OK
<shans_> one big question that pops up pretty much immediately is what to do about the disparity between what's representable in SVG and what's representable in CSS
<birtles> I'm not sure how best to proceed here, perhaps it's best if someone has an attempt on their own and then we discuss it?
<birtles> shans_, what do you mean?
<shans_> ok, so in SVG we model elements
<shans_> and animations are discussed with reference to the specific elements that they modify
<shans_> but CSS models selectors
<shans_> and animations apply to elements only because the elements happen to match the selectors which specify those animations
<shans_> this actually ends up being a surprisingly deep (and often subtle) difference
<birtles> yeah, I started thinking a bit about that
<birtles> one attempt I made at resolving this is you have an Animation object
<birtles> it's tied to an element
<cabanier> once an animation is applied to an element (with a selector), it becomes its own object
<birtles> <animate> elements currently generate only one
<birtles> CSS selectors can generate many of them
<shans_> that will work, but has a couple of disadvantages
<cabanier> such as?
<shans_> (1) we can't reference the generator of the Animation object, even though it exists in CSS
<birtles> for (1), why not?
<cabanier> is that a problem? seems like a user could resolve this themselves.
<shans_> (2) we can't support widget animations from a CSS perspective
<shans_> birtles: well, we *could* expose it to the API. But then the primitive is the Animation generator, not the Animation object.
<birtles> why not have both? Animation objects, have a reference to their generators?
<shans_> that sounds workable
<shans_> it's more complicated, but ultimately better, I think :)
<birtles> yeah, there are still lots of questions in my head
<shans_> it opens up questions like what happens to in-flight animations if the generators are tweaked
<birtles> yeah, I've been thinking about that
<birtles> I was considering saying that the animation doesn't change
<birtles> i.e. it keeps a copy of the generator's params
<shans_> that doesn't support CSS though
<birtles> (in practice you'd use copy-on-write though)
<birtles> yeah, it depends when the animations get generated
<shans_> because with CSS, if you modify the underlying rule, then even in-flight transitions/animations are impacted, I think
<birtles> no, CSS takes a snapshot
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@192.150.22.150) has joined #webanimations
<shans_> birtles: oh? Awesome, that's actually much better
<birtles> CSS takes a snapshot, that's actually why I was thinking of defining it like that
<birtles> SVG conveniently doesn't define what happens
<shans_> hehe
<birtles> so we can just make SVG use CSS' behaviour
<cabanier> so, is the conclusion that existing animations are not impacted? (I dropped off)
<shans_> yes
<birtles> according to CSS, they are not impacted
<cabanier> is that in the spec?
<birtles> yeah, let me find it
<birtles> "The values used for the keyframes and animation properties are snapshotted at the time the animation starts. Changing them during the execution of the animation has no effect"
<birtles> http://dev.w3.org/csswg/css3-animations/#animations
<birtles> I wonder though, going forward, is that acceptable?
<birtles> do you know of any use cases where you might actually want in-flight animations to reflect updated parameters?
<shans_> we can always provide a method call to explicitly re-sync?
<birtles> yeah, that's true
<cabanier> that line is a little unclear. It sounds like the recalculation will happen if you stop the animation...
<birtles> hmm, I don't know
<birtles> you can't stop the animation, only pause it
<birtles> or remove it
<shans_> wrt the generators, minting an animation from a generator is an interesting process, at least in CSS, because the from and to property values are only completely specified at the point of generation
<shans_> for a simple example: .foo {transition-property: width; width: 100px; } .foo:hover { width: 200px; } .foo[wideVer]:hover { width: 400px; }
<shans_> for something more complicated, imaginve modifying the transition-time under the [wideVer] attrib selector too
<birtles> I don't quite get it, is that a problem? it sounds like it would be ok no?
<birtles> you only generate the animation when it is ready to fire
<birtles> at which point you know the values right?
<birtles> or you mean, what do you point back to?
<birtles> from the animation object?
<shans_> oh no there's no problem
<birtles> I had a very tentative go at working out some animation primitives, but one question I had was--are animations and transitions different concepts we want to model?
<shans_> my gut feeling is to try and keep them unified
<birtles> yeah, that was what I thought
<shans_> expose the difference in behaviour as different ways of manipulating the API rather than as different primitives
<cabanier> you have a lot of exeperience in that field.
<cabanier> they seem similar to me
<birtles> ok then we can start off by trying to keep them as one
<birtles> I'm surprised how much agreement we have on this
<shans_> I'm happy how much agreement we have :)
<birtles> I wrote a couple of brief notes about primitives which I can put on the wiki
<birtles> unless someone else wants to put up a proposal?
<shans_> nah, let's go with what you've put together :)
<shans_> I could take the primitives and try to apply them to some CSS scenarios
<birtles> alright, I'll write it up properly and we can discuss it next time
<birtles> I promise you there will be lots and lots of problems with it though :)
<shans_> heh
<birtles> but it's an iterative process :)
<shans_> yep
<cabanier> yes
<birtles> ok, let's finish this agenda item
<cabanier> email us when you post it and we can discuss it over email
<birtles> ok, are you free to meet again same time as last week?
<shans_> yep
<cabanier> yes
<shans_> oh, did you want to do feedback for the other thing?
<birtles> i.e. Shane/Brian: Friday, Rik: Thurs
<shans_> or are we out of time?
<birtles> yeah, we still haven't done item (3) yet
<birtles> I'm still good
<birtles> how are you Rik?
<cabanier> I'm ok too
<birtles> alright, well, let's move on to item 3 then---I think we all have a few actions from item 2
<birtles> feedback regarding the state machine proposal
<birtles> my feedback is: * I'm keen on addressing the widget use case and this seems really useful
<birtles> * I like the modularity of the proposal
<birtles> * BUT I would like to address some of the features of the proposal independently
<birtles> e.g. the proposal adds additive behaviour to animation
<birtles> I'd like to address additive behaviour in general
<shans_> absolutely
<birtles> work out a general solution for web animations independent of state machines
<birtles> same goes for some of the reversing behaviour I think
<shans_> yeah, I think so too
<birtles> and I think I'd like to do that first, and see how to build state machine behaviour on top of that
<shans_> that proposal was put together before we learned about this approach to unify CSS and SVG animations, so it's pretty specific to fixing holes in CSS
<birtles> yeah, there's a lot of stuff that's useful there beyond just state machines.
<shans_> I think that is OK (fixing reversing and layered animation first)
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@192.150.22.150) has joined #webanimations
<birtles> I was a little unsure about the edge completion behaviour but that's probably a detail to discuss later
<shans_> having built that demo, I can also do an analysis of the primitives that were missing (e.g. I have to emulate CSS events so that I know when state changes occur), which might let us build in *support* for state machines without having to model the state machines explicitly
<birtles> that would be great!
<shans_> ok, I'll try and get that done ASAP
<birtles> I'm just curious, did you consider SMIL's state stuff?
<shans_> no, we didn't
<birtles> http://www.w3.org/TR/SMIL/smil-state.html
<shans_> I'll look into it
<birtles> I haven't looked at it
<birtles> I think probably most of it is irrelevant
<birtles> but there might be some stuff we can learn from it
<shans_> a 5 second overview makes me think it's more about variables that can influence properties of an animation than about setting up state machines
<shans_> (i.e. state as in getState / setState, not state as in state graph)
<shans_> but definitely worth a closer look, to see if there's stuff in there we want to support
<birtles> yeah, might be
<cabanier> that spec seems of limited use...
<cabanier> shane's Edge syntax is more powerful
<birtles> yeah, I'm sure
<birtles> but I think it's still worth a closer look just to make sure we're not missing anything
<cabanier> I agree
<birtles> alright, so I think the main action here is that Shane is going to work out what primitives were missing for supporting state machines in CSS
<shans_> sounds like
<birtles> and there seems to be agreement that that first step is to build in the generally useful features of the proposal into the module
<shans_> and it looks like we've also added reversing and layered animations to the priority list
<shans_> yeah
<birtles> and then see what's still needed in order to support state machines
<birtles> yeah
<birtles> that's true, we have additional use cases for layering and reversing
<birtles> ok, well I'm happy to end here then, anything else you want to discuss?
<shans_> I'm good
<cabanier> me too
<birtles> alright, thanks very much!
<shans_> ok, see y'all thu/fri then :)
<shans_> thanks brian :)
<birtles> yep, see you then!
<cabanier> so, are we meeting again on thursday?
<birtles> yes, is that ok?
<cabanier> yes. Same time?
<birtles> yes, 16.00 PST
<cabanier> cool. Talk to you then.
<birtles> thanks!