22:01:23 RRSAgent has joined #svg 22:01:23 logging to http://www.w3.org/2012/01/11-svg-irc 22:01:26 Zakim has joined #svg 22:01:33 Chair: Cameron 22:02:05 vhardy has joined #svg 22:04:17 i do not have skyp.. hmm 22:04:26 dino has joined #svg 22:04:52 shans has joined #svg 22:05:21 birtles has joined #svg 22:06:43 patrickdengler_, we'll set up the zakim bridge 22:06:51 patrickdengler_, and get cyril to call in to it from here 22:08:37 ScribeNick: vhardy 22:08:51 Zakim, room for 5? 22:08:53 ok, heycam; conference Team_(svg)22:08Z scheduled with code 26631 (CONF1) for 60 minutes until 2308Z 22:09:04 Topic: Web Animations 22:09:07 Zakim, code? 22:09:07 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 22:09:13 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations 22:09:27 cyril has joined #svg 22:10:17 i'll dial in in about 35-45 minutes 22:10:32 cabanier has joined #svg 22:11:11 patrickdengler_, is it ok if we begin on brian's topic and you come in half way through? 22:12:45 thorton_ has joined #svg 22:14:16 jun has joined #svg 22:16:14 please begin brian's topic without me of course 22:18:32 RRSAgent, this meeting spans midnight 22:20:12 rrsagent, make logs public 22:21:11 Meeting: Sydney 2012 F2F day 2 22:21:31 Topic: Web Animations 22:21:32 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations 22:22:32 dino has joined #svg 22:25:28 Team_(svg)22:08Z has now started 22:25:35 + +1.206.734.aaaa 22:27:17 brian: this came out of the Seattle F2F to look at the features that are in SVG animations and not in CSS animations and then prioritize them according to usefulness. 22:27:22 ... I wrote a long document. 22:27:51 ... the first part is in response to the action, about features. This is input to the FX task force. 22:28:05 .... I have written it for CSS animations people who do not know SMIL. 22:28:37 ... I start by listing the differences. Then I created a few use cases. They may not be sufficient, I would appreciate additional use cases. 22:28:52 ... then, I have attempted to prioritize. 22:29:31 ... finally, this is what I would like to talk about, is the proposal for an element syntax that is a middle ground between CSS animations and SMIL animations. I would like to discuss the concept and see if there is support. 22:29:42 chris: how does this differ from what Patrick is proposing? 22:30:52 brian: Patrick is proposing to extend the reach of CSS animations in SVG so that you can animation more attributes by making them presentation attributes and animatable by CSS animations/transitions. My proposal looks at adding missing features in CSS Animations/Transitions, such as timing and synchronization. 22:31:23 ... Going through what I have written down, here is what is missing from CSS animations. 22:32:47 ... Timing. One major difference is that SVG animations have an absolute reference whereas CSS animations start on document load or at the time there is a property match. 22:33:37 dean: yes, this is pretty imprecise in CSS. The actual time is the first time it renders, and CSS does not specify when that time would be precisely. This means forcing a style resolution. There is no real way to kick start the animation precisely. 22:33:44 chris: is there a way to resolve this? 22:34:31 dean: implementations end up doing the same thing and it resolves ok. Things are similar enought that people do not notice. 22:35:09 As long as you're not trying to chain animations, yes, it's "good enough" right now. 22:35:34 Being able to specifically relate animations to a timeline and/or chain animations together is something I feel is important to eventually support. 22:36:47 shane: because the aniamtions are resolved on style resolution and style resolutions happen at different times, the user may get offsets between animations starts that he/she does not want and cannot control. 22:36:53 ChrisL has joined #svg 22:37:19 dean: the current behavior is kind of ok, but we need something more precise. 22:37:39 shane: I have a question about the SVG timing model. Can you sync. up two animations? 22:37:44 (several): yes. 22:38:43 ChrisL has joined #svg 22:39:13 (several): explain time conditions in SMIL, such as and 22:39:17 zakim, remind us in 8 hours to go home 22:39:17 ok, ChrisL 22:39:25 rrsagent, make logs public 22:39:41 rrsagent, this meeting spans midnight 22:39:52 brian: in point T1b), there is a description of the features available in SMIL. 22:40:12 zakim what is the code 22:40:19 zakim, what is the code 22:40:19 I don't understand 'what is the code', cyril 22:40:23 ... getCurrentTime and then call beginElement, you will get the same time. This could be better specified. 22:40:24 zakim, code 22:40:24 I don't understand 'code', cyril 22:40:46 RRSAgent, pointer 22:40:46 See http://www.w3.org/2012/01/11-svg-irc#T22-40-46 22:40:53 dean: In WebKit, for animations, we don't update/apply different times to the animation in the same script context. 22:41:07 rrsagent, make minutes 22:41:07 I have made the request to generate http://www.w3.org/2012/01/11-svg-minutes.html ChrisL 22:41:11 .... if you add several animations, they appear to start at exactly the same time. 22:41:50 +??P1 22:42:00 ... CSS does not specify when the animation starts between the time the style is set and when it really kicks in (at style resolution or first rendering). 22:42:01 - +1.206.734.aaaa 22:42:33 heycam: in SVG animation, you can specify an absolute time. In CSS animations, you can only specify somethign to start relative to the current time. 22:42:39 brian: yes, that is correct. 22:42:55 ... correct sync. with events is possible in SMIL animation. 22:43:12 (where by absolute time I mean an absolute time within the document timeline, not a wallclock time) 22:43:42 shane: if we modified CSS animations to better define the time animations start, would that be desirable? 22:43:52 dean: yes. 22:43:57 Meeting: SVG WG Sydney 2012 F2F day 2 22:44:30 dean: I think brian will go on to explain how an absolute timeline could work. 22:44:43 dean: I think that is ok. There should be a way to start at an absolute time. 22:44:54 Sage. 22:45:51 brian: Below T1 c), I propose ways to have a proper timing, like defining a time container in HTML. We can use inspiration from SVG Tiny. 22:46:54 heycam: we already want a unified notion of time line for requestAnimationFrame and performance APIs, so we should also use a unified notion for CSS animations and SMIL animations. 22:47:18 cyril: why did not CSS animation use a time container to begin with? 22:47:31 shane: because it was defined to start at 'style resolve time'. 22:47:44 brian: my proposal addresses these issues with proposals. 22:48:05 ... I propose to consider the timelneBegin, as we have in SVG animation. 22:48:18 ... I have a few suggestions to introduce the same in CSS animations. 22:48:26 cyril: this is something we cannot decide here, right? 22:48:41 brian: yes, this is input to the FX task force, an ACTION I had from the Seattle F2F. 22:48:52 CSS Animations were defined in a very limited and weak way at first. They simply run as long as the property applies, starting "when the property starts to apply" and stopping when it stops. 22:48:57 ... we are not trying to decide here now. I am looking for input. 22:49:07 By the way, Brian, excellent doc. Lots of food for thought. 22:49:17 brian: moving on to T2. 22:49:41 .. in SVG animations, you can schedule multiple intervals. There is only one in CSS animations. 22:50:03 heycam: CSS animations only support something like 'style resolution time' or 'style resolution time + offset'. 22:50:27 brian: yes, that is true, but you cannot control playing the animation multiple times declaratively. 22:51:00 .... if introduce that feature, we need to decide how overlaps of the same animation are handled. SVG animations specify how to handle that type of situation. 22:51:05 From pure CSS, we'd have to add another at-rule or something that defined an animation separately, so we could tell it to start based on various things. 22:51:22 heycam: in SVG animations, you can have indefinite values in the list, and then you can start the animation with a script call (beginElement). 22:51:24 Alternately, create a decent JS API for constructing Animation objects. 22:51:42 Or rely on the increasing merging of SVG into the other languages and have an element in SVG for it. 22:51:50 ... the CSS equivalent is to manipulate the style to set the animation-name to none and then set it again. 22:52:29 brian: going on to T3, aborting animation. There in an end attribute in SVG animations. 22:52:35 ... that is not available in CSS. 22:52:45 Note: I do *not* think that extending the power of the 'animation' property is the right direction here for almost any of this. 22:53:12 'animation' does a single simple thing and does it reasonbly well. It shoudl be considered a shortcut for applying animations while an element is in a particular state, not the canonical way to interact with animations. 22:53:14 vhardy: you can abort an animation in CSS, but not declaratively, you need to manipulate the style. 22:53:16 imo 22:53:44 shans has joined #svg 22:54:05 We should be considering animations as objects separate from the 'animation' property when thinking about how to address most of these. 22:54:23 (Similarly, 'transition' does a single simple thing well.) 22:55:30 -??P1 22:55:31 Team_(svg)22:08Z has ended 22:55:31 Attendees were +1.206.734.aaaa 22:55:33 TabAtkins, ok that's good. The "proposals" aren't serious, just showing how these features relate to CSS Animations. Other proposals are very welcome. 22:55:38 chris: Microsoft has expresssed that they do not want to implement SMIL animations. So if we want more features or address the problems, we need to add features to CSS Animations. 22:55:41 i agree with Tab (mostly - I do think we can extend the animation property to solve some of the things in Brian's document in a simple manner) 22:56:16 vhardy: may be if we can demonstrate that more features are needed and that adding them to CSS animations creates the same amount of work as implementing SMIL animations, Microsoft may reconsider their position? 22:56:16 dino: Yeah, some of the things may be appropriate for extending 'animation' - this is a long list. ^_^ 22:56:39 vhardy: I also agree that having a common underlying model that different syntaxes / markups map to is the right architectural approach. 22:57:01 vhardy: I still doubt that they'd like to implement two separate animation models. We'd like to remove SMIL from Chrome, too - our implemenation is shit and a big security hole. 22:57:13 Fixing the security bugs is a "reimplement the whole thing"-level task. 22:57:37 I do agree vehemently with the goal to not make the CSS syntax for animations much more complex than it currently is. I'd rather go without features in the CSS syntax than make things confusing. I'd prefer a JS API. This goes quadruple for transitions. 22:58:39 chris: people do not want to have SVG animation elements because they want styling and animations seperate. 22:59:06 ... the animations could be started from a stylesheet but pointing to a resource where the animations are defined. 22:59:27 Team_(svg)22:08Z has now started 22:59:34 + +1.425.868.aaaa 23:00:29 vhardy: I think that animations are sometimes content sometimes styling. For example, if you do a cartoon, animations are the content. If applying to an HTML dialog, they are styling. 23:00:36 +??P1 23:01:00 vhardy: also, I think that because there are issues with SMIL engines implementations, we should not conclude that the issue is necessarily with SMIL itself. 23:01:03 zakim, P1 is us ;0 23:01:03 I don't understand 'P1 is us ;0', cyril 23:01:28 zakim, p1 is SVG_WG 23:01:28 sorry, ChrisL, I do not recognize a party named 'p1' 23:01:36 zakim, ??P1 is SVG_WG 23:01:36 +SVG_WG; got it 23:01:38 vhardy: there are a lot of good things in the SMIL model that I hope can be the underlying model for a common animation solution applying to CSS, Scripting (and obviously SMIL). 23:02:18 zakim, aaaa is Patrick 23:02:18 +Patrick; got it 23:02:38 heycam: I think the SMIL scripting APIs are limited. 23:03:17 vhardy: yes, my point is that if we defined better scripting APIs for animations, we should leverage the same underlying model and use the SMIL timing model as much as possible. 23:04:09 + +1.650.253.aabb 23:04:10 brian: I don't agree an API will solve everything. Sometimes, we need more APIs for animation, but I do not think that will be enough. I think declarative animations is needed. We need a way to do reasonably sophisticated animations declarative animations. 23:04:12 zakim, aabb is me 23:04:12 +TabAtkins; got it 23:04:12 chris: I agree. 23:04:18 vhardy: I agree. 23:05:05 cyril: we've had SVG animations for a long time, they are declarative, and no one is using it. Why are people using CSS animations more. 23:05:33 s/more/ more, specifically in authoring tools/ 23:05:46 chris: there is not much room for a tool for CSS in general, and in particular for CSS animations. 23:06:02 chris: I do not expect tools editing CSS animations in general? 23:06:10 rik: why not? All the information is there? 23:06:23 chris: I am talking about reading content that was not written by the tool? 23:06:34 ... for CSS in general. 23:06:58 cyril: I agree with brian in general. It is better to have a declarative solution for authoring tools. 23:07:27 brian: regarding the adoption, CSS animations apply to HTML and SVG animations to SVG. There is much more HTML than SVG, so that explains the difference in adoption. 23:08:30 There is always this agrugment between declarative and code. Historically, code in browsers meant x-scripting issues. In non-HTML contexts, declarative vs. code has become a bit of a redherring. Yes, tools and tool declarative syntax better, but the harder you push declarative support, the harder it is to understand the concepts, and thus the harder it is to tool them. 23:08:48 Does that make sense? 23:09:21 vhardy: I think one factor too is that CSS animations, at least initially, have been used for UI effects that do not require as many animations and synchronization as you would need for complex cartoons for example. For the types of animations enabled by SMIL, tools are needed and there have been a lack of tools so far. 23:09:25 and untoolable 23:09:36 declarative is still code :) 23:09:49 tab: I agree with Patrick. 23:10:04 heycam: I think the declarative v.s. scripting is a bit off-topic. 23:10:44 brian: the argument put forward is that all we need is a very elementary CSS animation and then a scripting API. I disagree with that position. 23:10:51 vhardy: yes, I agree. 23:11:27 brian: yes, it is not just about tool support. Security is one of the major issues, probably the main compelling reason. You can use animations where you cannot use scripting. 23:11:57 brian: back to T4 on synchronizing animations. That is in SVG animations and not in CSS. 23:11:58 I respect Brian's well done analysis. My position is that if you increase the feature set of CSS Animations, and back it with a richer API, that this is a better balance long term. That''s all. 23:12:36 ... there is a proposal to how to add synchronization to CSS animations, it is rough. 23:12:45 ... it is a big feature. 23:13:04 .... T5. Seeking the document timeline. 23:13:22 ... that would be useful in CSS animations as well. 23:13:48 dean: yes, this is useful. CSS animations does not really talk about time containers. So theoritically, each animation is in its own timeline. 23:14:01 brian: T1 may be a pre-requisite for this feature. 23:14:46 chris: having unsynchronized timelines is not useful, because it is common to need to sync. animations. 23:15:07 cyril: do implementations implement time seeks? 23:15:12 brian, ed: yes. 23:15:19 cyril: Is it well specified? 23:15:26 brian: yes, it is decent. 23:15:44 cyril: do we have tests in the test suite for those? 23:15:49 ed: yes. 23:16:11 brian: T6, ability to pause the timeline. 23:16:30 .. T7: repeating by duration instead of duration count. 23:16:49 ... this might even be more important with time containers. 23:17:25 dean: this is not currently an issue because you always know the duration of children. 23:17:43 brian: it is a convenience, and you can often calculate it and use repeatCount. 23:17:58 dean: what is an example of why you would use repeatDuration? 23:18:25 brian: when you want to sync. on the duration of other animations and not want to compute how many iterations that makes in the other aniamtions you are trying to limit in time. 23:18:47 brian: T8, triggering animations from arbitrary events. 23:19:54 cyril: there is a difference between using the begin event and the begin sync. arc. 23:20:16 is different from 23:21:01 brian: there are differences, the most important one is negative offsets. With sync. base timing, the time will be resolved, but with the event base, the animation will only start after the event has fired. 23:21:10 ... there are also differences with seeking. 23:21:21 ... so this is the argument for keeping sync. based timing. 23:21:53 [brian shows a demo] 23:22:25 brian: showing a demo of a video and an animation sync. up with the video. 23:22:26 http://brian.sol1.net/svg/demo/video.html 23:22:34 dur="1s" repeatCount="indefinite" fill="freeze" 23:22:37 begin="video.playing" end="video.pause; video.ended"/> 23:23:13 dean: I most cases, I have found writing content to do something like this, you want to triger the event with a conditional expression. 23:23:23 ... e.g., you click and some other state exists. 23:24:37 vhardy: when coupled with custom events, this provide a pretty elegant solution, because you can triger animations on application events. 23:24:46 sorry, what? 23:26:41 BREAK for 15mn then continue on Brian's topic. 23:27:17 -TabAtkins 23:28:08 The only topic I have for CSS Animations is going to be: are we all good with this proposal : http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0003.html 23:28:54 I've not heard any additional feedback beyond Dean's, which is incorporated, and I have otherwise heard support. If this is the case, I'd like a resolution to accept this, at which point I am happy to make the edits in the specification. 23:28:57 Yes, I'm good. 23:28:57 If not, let's discuss. 23:30:55 I had hoped to have a prototype to run on webkit, firefox and Opera, but it only runs on IE so far. Once I have the prototype running on all browsers, I will put the code on some open source place so people could drop it in and make their sites backward compatible. 23:32:40 patrick, I sent some feedback on elevation and azimuth,did you see that? 23:39:23 I saw your feedback on elevation and azimuth. I believe that is included in the link. If I recall you noted that these could and should be deprecated in the CSS Aurul spec so we don't have to rename them. Is that correct? 23:43:48 cabanier has joined #svg 23:44:37 yes 23:45:05 krit1 has joined #svg 23:47:28 patrickdengler_, since we're not having an official FX meeting here, are we able to officially resolve that? 23:47:28 dino_ has joined #svg 23:47:35 patrickdengler_, we can say whether we (SVG WG) is happy with it 23:48:01 THat's fine, let's start there though. Dean is good with it and perhaps he can shepard it over to CSS 23:48:16 ok 23:48:29 we will just wait a few more minutes for vincent to return 23:48:31 Zakim, code? 23:48:31 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 23:48:38 Zakim, who is on the call? 23:48:38 On the phone I see Patrick, SVG_WG 23:50:59 zakim, room for 5? 23:51:01 ok, ChrisL; conference Team_(svg)23:50Z scheduled with code 26631 (CONF1) for 60 minutes until 0050Z 23:51:04 I am on the line 23:51:24 -Patrick 23:51:25 -SVG_WG 23:51:25 Team_(svg)22:08Z has ended 23:51:26 Attendees were +1.425.868.aaaa, SVG_WG, Patrick, +1.650.253.aabb, TabAtkins 23:51:30 Team_(svg)23:50Z has now started 23:51:33 +Doug_Schepers 23:51:37 +Oliver_Goldman 23:51:58 +Patrick 23:52:44 Zakim, code? 23:52:44 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 23:53:20 +[IPcaller] 23:53:57 ScribeNick: heycam 23:54:09 Topic: continuing Brian's animation topic 23:54:16 BB: first A1, animateMotion 23:54:19 … that's not possible in CSS 23:54:22 … seems to be quite useful 23:54:31 … we've also already resolved to support a more general case of animation of pairs of values 23:54:38 … that's an abstraction of animateMotion I guess 23:54:52 … (these are animation value features not in CSS) 23:55:05 … next, the ability to combine animation values with underlying animations, instead of replacing 23:55:14 … I think Dean mentioned in Seattle that there's already been some proposal to add something like that 23:55:41 … wasn't sure if that referred to this, or adding separate animations together 23:55:53 CM: what's the difference between A2 and A3? 23:56:04 BB: in SVG they're the same, since they both use the same concept of underlying animation values 23:56:14 … A2 is just considering the base value of the attribute 23:56:27 … A3 is an extension of that where you can have additive animations 23:56:40 DJ: A3 is what has been requested for CSS Animations before 23:57:07 BB: one other difference is that I believe CSS Animations takes a snapshot of the values when it begins animating 23:57:11 … in SVG animations it's live 23:57:19 … if the underlying value changes then the animation will reflect that change 23:57:47 CL: does that mean if the script manipulates an already running animated animation property it doesn't have any effect until the animation ends? 23:58:00 DJ: the only way you could see something happen is if the script manipulates the animation attributes 23:58:21 … in CSS if you have an animation on an element, manipulating colour e.g., if you set the color on the style property of the element it's never going to change while the animation is running 23:58:26 … since the animation always overrides it 23:58:45 … if while the animation is running, you find the @keyframe and update the values there, the animation also doesn't change 23:59:09 … you might expect to be able to change the duration while it's running, but the spec says that shouldn't work 23:59:18 … which gets back to restarting animations, you have to remove and replace it 23:59:22 … which is annoying 23:59:35 BB: another point about A3 is that this is where the animation model comes in, which animation goes on top of which 23:59:39 … some people are not keen on that model 23:59:40 "As Anne van Karsten points out" - new nickname!!! 23:59:56 … it might be worth reassessing how animations combine together 00:00:07 … the last animation feature is combining animation with itself, that's accumulate="sum" in SVG 00:00:12 DJ: how often is this used in practice? 00:00:21 BB: I suspect not that often 00:00:26 … but I don't really know 00:00:43 CC: what is "SVG's endpoint exclusive timing model"? 00:01:02 BB: that's where at t = 0, the animation effect is applied, but at t = 1 it is not applied 00:01:25 … that's important when you accumulate 00:01:30 … otherwise you'd have overlap 00:02:31 … it's also significant when you have absolute time references 00:02:51 … if you query the animation at that exact end point, the animation is not being applied so the unanimated value will be returned 00:02:58 … now, a couple of other quick items 00:03:12 … document structure -- SVG allows you to interleave animation content with the stuff you're animating 00:03:19 … Anne pointed out that this is possible with CSS if you use