Web Animations/Meetings/Meeting 2
< Web Animations | Meetings
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!