Web Animations/Meetings/Meeting 4
< Web Animations | Meetings
Time, location: 13 Feb 16:00 PST / 14 Feb 11:00 AEDT / 14 Feb 09:00 JST, #webanimations
Agenda
- Meeting in Tokyo
- Object primitives
- Prioritisation
Synchronisation discussion
Log
<shans> hey guys <birtles> hi Shane! <shans> I'm going to have to finish right on the hour this time round, sorry <birtles> no problem <shans> hey <shans> do you want to track agenda items and meeting minutes on the wiki? <shans> or somewhere like that? <shans> (Rik's email with our discussion summary made me think it might be useful) <birtles> yeah, sounds good <birtles> I have all the past meetings logged, maybe you do too <birtles> maybe we just need a page which lists the agenda items for each meeting plus a link to the IRC log, then a section for the next meeting's agenda <birtles> it sounds like you're busy, do you want me to do it? <shans> oops <shans> sorry <shans> yeah maybe <birtles> ok, no problem -->| cabanier (IceChat77@192.150.22.150) has joined #webanimations <birtles> ok, are we ready to go? <cabanier> hi, <cabanier> yes <birtles> Rik, Shane just suggested we make a meetings page so we can set up the agenda in advance and keep a log of past meeting minutes <cabanier> sounds good. We don't want to rehash things <birtles> I'll try to get that set up today <birtles> but, for now, here's what I have on the agenda: <birtles> 1) Meeting in Tokyo <birtles> 2) Synchronisation discussion <birtles> 3) Object primitives <birtles> 4) Prioritisation <birtles> also, Shane has to leave in 1hr <birtles> anything else to add to the agenda? <cabanier> me too, so that works well <shans> sgtm <cabanier> no <birtles> ok great, so (1) meeting in Tokyo <shans> wait, actually, can we move the sync discussion last? <birtles> sure <shans> we spent the entire hour on it last week, so it'd be nice to get 3) and 4) looked at <birtles> alright, good point <shans> cheers :) <birtles> so, regards Tokyo, I take it Mar 28-30 is ok for everyone <shans> yes <birtles> so I think we're ok to make bookings <cabanier> yes. I'm unsure Vincent will be able to make it but it's good for me <shans> righto. Are you happy to host at mozilla? <birtles> yes, it's fine---how does it suit you though? <shans> suits me fine <birtles> I was wondering if you and Alex prefer to meet at Google? <birtles> ok then, Mozilla it is <shans> I'll get some budget together for a nice dinner one night <cabanier> :-) <birtles> woah, ok :) <shans> (if I can :-)) <birtles> yeah, I don't know what I can promise here, but at least there's a room :) <shans> that's all we need. Oh, do you have public wifi set up? <cabanier> as long as we fit and there's internet <birtles> yeah <shans> great <birtles> there's wifi <birtles> ok, well, let me know if you have any questions about transport etc. too <birtles> otherwise I think that's all we need to discuss for now <birtles> so (2) is object primitives <birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/API_Primitives <birtles> is my very early attempt <birtles> I haven't really put much thought into it, but hopefully it's a start <shans> I like it <shans> I think we're going to need to pay careful attention to two things: <shans> (1) the minting of Animation objects from Animators. <shans> (2) making sure that Animator objects fit the CSS model <birtles> wrt to (1) what are the particular issues you have in mind? <shans> wrt (1): we need to make sure it's easy to fill in all the blanks, which could be e.g. derived from current style <cabanier> isn't an animator just a CSS animation? <shans> wrt (2), CSS animations layer. For example I can selectively override the duration of an animation with a specific style rule. <birtles> an animator is like an animation definition <shans> so if we get the Animator interface correct, a CSS animation is a stack of Animators. But we need to get the interface correct. <shans> hmm <cabanier> shane, how is it a stack of animators? <birtles> shans, a stack of Animators? why a stack? <shans> "CSS animations layer" is a really bad sentence. <shans> CSS animations stack on top of each other. <shans> OK, take this example: <shans> .a { animation-name: foo; animation-duration: 2s; } .b { animation-duration: 4s; } |<-- cabanier has left irc.w3.org:6665 (Connection reset by peer) <shans> (waiting) -->| cabanier (IceChat77@192.150.22.150) has joined #webanimations <shans> did you get the example Rik? <cabanier> sorry. no <shans> a { animation-name: foo; animation-duration: 2s; } .b { animation-duration: 4s; } <cabanier> I switch irc clients but it's still happening <shans> hmm :( <shans> so we could create an Animator per element, when either .a or .a.b was encountered <shans> (class="a" or class="a b") <shans> but this is likely to encounter some opposition from the CSS people, as doing something like updating the .b style rule becomes expensive <birtles> (sorry, back) <cabanier> is there a need for animator? <shans> so I think it's better to create an Animator per rule (one for .a, one for .b) <shans> then allow them to stack <shans> hmm, you could probably do without one <birtles> I don't know enough about how CSS is implemented but is there another option there? <birtles> i.e. make an Animator for each unique application of animation? <birtles> i.e. when you encounter the combination of .a and .b create an Animator for that <shans> well that's the option that gets expensive, I think <birtles> but you don't have one Animator per element <shans> because if the rules for .a or .b change you need to go back and find all the already-created Animators <birtles> I thought the expensive option was one Animator per element <shans> the thing that I think will be expensive is finding multiple Animators and updating them <shans> oh wait, I see what you're suggesting <shans> sorry, misunderstood <shans> hmm, I think that wouldn't be expensive <birtles> yeah, I'm just not sure how things are currently implemented <shans> but I'm not sure if it would be very easy to implement. The advantage of stackable Animators is just that they fit neatly with the way the CSS engine works (at least in WebKit) <cabanier> how would you create such an animator? <birtles> Rik, I think there are two questions there <shans> heh <shans> which do you mean thne? <birtles> there's creating purely scripted Animators <birtles> e.g. animator = new Animator() <birtles> animator.animate(NodeList) <birtles> but then there's question of, once you've created a CSS Animation, how do you fetch the corresponding Animator object(s) <birtles> and, umm, I'm not really sure about that bit yet <birtles> :) <cabanier> yes, I'm fuzzy on that one <shans> so there's two paths in, like you've discussed <birtles> one option is to try and align the current CSS Animations KeyFramesRules APIs <shans> div -> Animation -> Animator <shans> and CSS Rule -> ??? <birtles> maybe there's something in getComputedStyle we could override? <cabanier> shane: ah, you would get to an animator through an animation if it's defined with CSS. <birtles> cabanier, yeah, that's one path <shans> if we have an AnimatorStack, then I think you'd go CSS Rule -> AnimatorStack <shans> no wait <shans> div -> Animation -> AnimatorStack -> Animator <shans> and CSS Rule -> Animator <birtles> and CSSKeyFrames rule more-or-less corresponds to the AnimationFunction part of the API <cabanier> so, animator would be allowed to be partially constructed <shans> I guess though that this will be ultimately up to the CSSWG and SVGWG, right? <shans> Rik, what do you mean? <cabanier> in your example, the style on a has duration as undefined <cabanier> b has the animation-name undefined <shans> oh. Yes. <shans> not partially constructed as much as constructible with invalid values / references <cabanier> the animatorstack collapses them and produces a resolved animation <cabanier> correct <birtles> I wonder if it's possible to do without creating another object type <birtles> e.g. just add an attribute to the Animator which references the previous Animator in the chain? <birtles> or something of that sort? <shans> or allow an Animator to be built around a vector of Animators, or something like that <birtles> just for the sake of keeping the API simple <shans> sounds OK to me <shans> I think an Animator can participate in multiple chains though, so embedding a list may not work <shans> wait, let me whip up an example <birtles> oh ok <cabanier> what if we call the animatorstack the animator and it refers to a stack of CSS rules? <shans> .a { animation-name: foo; } .b { animation-duration: 2s; } .c { animation-name: bar; } <shans> now .b .a and .b .c are both potential stacks <shans> if we refer to CSS rules then we're bleeding CSS directly into the API. That mightn't be a problem, but we need to decide whether it is or not. <birtles> yeah, I'm a little uncomfortable with that <birtles> I'd like an API that also makes sense from (a) a purely scripted context, (b) SVG context <cabanier> OK <shans> yeah I think I'm with Brian on that <birtles> but let me just check, the main reason we're going with the stacking approach is so CSS handling is performant? <shans> I think that there might be some feature advantages too, but that's the initial reason, I think <shans> (performant, and maps well) <birtles> yeah, the mapping is important too <birtles> I think <cabanier> whatever we come up with needs to be expressible in script and css, correct? <shans> I'll try to think of some use cases that might benefit from that approach (independent of css or svg) <shans> absolutely, yeah <birtles> I guess it depends, if you get an Animator corresponding to some CSS, do you expect to be able to modify it and have the CSS update? <birtles> what about features which aren't available in CSS? |<-- cabanier has left irc.w3.org:6665 (Connection reset by peer) <shans> Brian - ooh, interesting question <shans> (waiting) -->| cabanier (IceChat77@192.150.22.150) has joined #webanimations === CTCP version reply ``IceChat 7.70 20101031'' from cabanier <birtles> Rik, did you get my question? <birtles> "if you get an Animator corresponding to some CSS, do you expect to be able to modify it and have the CSS update?" <birtles> and what about features that aren't available in CSS? <cabanier> I believe not <shans> I'd like it to, if possible <shans> but I think that's going to be a difficult thing to work through. <birtles> (ChatZilla is working pretty well for me by the way :) ) <cabanier> (it's the mandatory virus scanner that they installed last month) <cabanier> (can't disable it) <birtles> (ah, that's annoying) <birtles> yeah, I think we're going to have to draw some lines regarding interaction between script and CSS <birtles> (and SVG too for that matter) <shans> if the CSS animation *is* the Animator <birtles> i.e. some sorts of interaction is mapped between the two, but some sorts aren't <shans> and there are hooks in the script for events from changes to the animator <shans> then it could be up to CSS <shans> and if unsupported features are poked, then that's fine, they just can't be represented by the CSS syntax. i.e. CSS is always a representation of the truth, which is the web animation component <cabanier> Shane, sorry, I didn't get that <cabanier> if you change the animator, it will change the css too? <shans> if you change the animator <shans> then an event fires <shans> it's up to the CSSWG to specify that this event should be captured and inspected to modify CSS rules. <shans> (likewise with SVG) <birtles> events scare me all of a sudden :) (after our synchronisation discussion) <shans> haha <birtles> we might be able to define a really basic Animator interface <shans> I think in this instance they're OK <birtles> e.g. I think the use cases are things like: <cabanier> ok. so, the animator would look through it's stack of rules, determine what rule was changed and fire an event for that. <birtles> a) user writes up an animation in CSS, fetch the Animator object via script and applies it to different elements in the page <birtles> b) user modifies the duration on the Animator and applies it to other elements <birtles> pretty simple stuff <birtles> maybe Animators created via CSS and via script don't need to have all the same facilities, just a basic common interface <shans> yeah although the script should have the superset of features, I think <birtles> yeah <birtles> Shane it sounds like you have some good ideas---do you want to update API primitives page (or make a new one) with some ideas? <shans> sure, I'll update in-place and tag suggestions with my name <shans> (so we can track what's going on) <birtles> sounds great <cabanier> yes <birtles> ok, shall we move on to (3) prioritization? <shans> yep <cabanier> ok <birtles> I wanted to go through http://www.w3.org/Graphics/fx/wiki/Web_Animations#New_features and assign priorities P1, P2, P3 to them <birtles> but we only have 15min <birtles> is it more important to cover synchronisation today? <shans> maybe we could just go through quickly and see where we agree? <birtles> ok so let's define P1, P2, P3 <cabanier> synchronisation will take more time <cabanier> ok <birtles> P1 - Not negotiable, must have ? <birtles> P2 - Really want, but we can put off to another version if absolutely necessary <birtles> P3 - Nice to have if possible, but we can live without ? <shans> sgtm <cabanier> ok <birtles> Ok, DOM 3 key identifiers = P3? <cabanier> yes <shans> +1 <cabanier> better through script <birtles> Adaptive duration -- do I need to explain this? <shans> not to me <shans> P2? <birtles> I think so <cabanier> what does it do? <cabanier> wait. OK <birtles> so currently in SVG and CSS you always have a fixed duration <birtles> this lets you specify other ways of calculating the duration <cabanier> I'd say p3 <birtles> (e.g. based on when another animation start, or some pace you want to mantain) <shans> ok, no agreement, let's move on (is that how you want to do this?) <birtles> yep, we'll just record our respective preferences in that case <shans> great <birtles> next, time containers <shans> P1 <birtles> p1 <cabanier> yes <birtles> next, ability to start animations before document load <shans> P3 <birtles> p1 for me <birtles> :) <shans> heh :) <birtles> it lets you show a spinner while the document is loading <shans> yeah but you can get around that with progressive loading <shans> argh wait <shans> we're supposed to just keep going ;-) <birtles> we can discuss a little I think <shans> yeah probably <cabanier> that's ok <cabanier> can't you already do this with CSS? <cabanier> what's needed? <birtles> no, the earliest a CSS animation can start is document load <shans> so you can have an initial load phase then pull more stuff in later, right? <birtles> SVG 1.2 Tiny's timelineBegin="onStart" is one option <birtles> animations can start as soon as parsing completes <birtles> i.e. the end tag is hit <birtles> ok, sounds like we need to come back to this <birtles> and discuss more <cabanier> yes. might be out of scope too <birtles> next, motion on a path <cabanier> p2 <birtles> svg is p1 <shans> p1 <birtles> css is p2 for me <shans> it's one of the major pain points for css <birtles> more general functional notation is p2 for me <cabanier> you can have multiple points so you mimic the path <shans> yeah I'd agree with that <birtles> I'm ok with saying, use SVG for motion on a path, but it'd be nice if you didn't have to <birtles> ok next, state machines <shans> wait one sec <shans> isn't this new features to include in the API? |<-- cabanier has left irc.w3.org:6665 (Connection reset by peer) -->| cabanier (IceChat77@192.150.22.150) has joined #webanimations <cabanier> (last I saw was: wait one sec) <shans> isn't this new features to include in the API? <birtles> which is a really really good question <shans> so I was thinking being able to represent paths in the API was P1 <birtles> I agree <birtles> this is difficult---trying to prioritise and define what belongs in script/SVG/CSS at the same time <cabanier> not sure if it's as important as time containers <shans> ok, let's leave it and move on <cabanier> Ok <shans> well, I think ignore SVG/CSS <shans> concentrate on "what features do you want to see in animations on the web in the future" <birtles> yes, good <birtles> next, state machines <shans> if we do our job right, CSS and SVG will have a really easy path to adopt the features, and even if they don't people will have access to the script interface <shans> P1 for me ;-) <cabanier> p1, yes <birtles> I'm p2, just because I can live with shipping it in a later version if we lay the groundwork for it in this version <birtles> ok, let's finish with interpolation <birtles> interpolating in colour spaces other than sRGB/linearRGB <cabanier> no! <cabanier> p3 <shans> p3, but without the vehement rejection <birtles> ok, I thought HSL was pretty useful <birtles> p2 for me <cabanier> :-) <birtles> next, simpler interpolation between two paths <cabanier> that would be nice <shans> p...1.5 <birtles> maybe even between arbitrary paths <cabanier> p2 <birtles> yeah, p2 <birtles> ok, I think that's it for today <shans> really fricking powerful and useful, but definitely something we can defer <shans> yeah righto p2 for that <birtles> we can continue next time <shans> thanks rik, brian :) <cabanier> inverse kinematics are more powerful <birtles> thanks Shane! <cabanier> OK <birtles> thanks Rik! <cabanier> next week or thursday? <birtles> oh, actually I have compulsory company health check then :( <birtles> can we do Wed/Thurs? <birtles> i.e. one day earlier? <cabanier> compulsory? <birtles> or otherwise, same time next week <birtles> yeah <cabanier> either works for me <birtles> well let's keep the momentum going then and meeting in two days time <birtles> ok with you Shane? <cabanier> I think he's gone... <birtles> yeah, I think so <birtles> I'll email later <cabanier> OK <birtles> thanks again Rik! <cabanier> you too brian! -->| shans_ (shanesteph@74.125.56.18) has joined #webanimations <shans_> sorry, yeah I'm down with meeting on Friday <shans_> oh wait <shans_> yes wed/thu is fine with me too <birtles> ok thurs our time, wed for Rik