View source for Web Animations/Meetings/Meeting 5

Time, location: [http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=2&day=16&hour=0&min=0&sec=0&p1=234&p2=240&p3=248 15 Feb 16:00 PST / 16 Feb 11:00 AEDT / 16 Feb 09:00 JST], [irc://irc.w3.org:6665/%23webanimations #webanimations]

== Agenda ==

# [[Web Animations/Requirements#Prioritization|Prioritization]]
# <del>[[Web Animations/API Primitives|API / Object primitives]]</del>
# <del>[[Synchronization Approaches Discussion|Synchronisation discussion]]</del>

== Log ==

<pre style="white-space: pre-wrap">
<shans> so
<birtles> hi guys, you ready to meet?
<shans> :)
<cabanier> I'm here. Connect over wifi with my mac.
<cabanier> Hopefully it will work better
<birtles> (= no virus scanner?)
<cabanier> not on my mac :-)
<birtles> ok, sounds good :)
<birtles> I put an agenda up: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings/Meeting_5
<birtles> 1) API / Object primitives
<birtles> 2) Prioritization
<birtles> 3) Synchronisation discussion
<birtles> anything to add? re-ordering etc.?
<shans> well maybe finish 2) first?
<birtles> sure, suits me
<shans> btw I haven't done much re: 1) yet
<shans> sorry :(
<cabanier> sounds ok to me
<birtles> ok, that's fine, it should be quick then :)
<cabanier> yes, these meeting are pretty close to eachother
<birtles> yeah, especially this one
<birtles> let's make it quick then--at least it will be a while until the next one
<birtles> so (2) prioritisation: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Requirements#Prioritization
<cabanier> OK
<birtles> I moved the requirements to a separate page because it was getting too long
<birtles> I think we are up to "Animation target" section
<birtles> but I also realised that under "Timing" I don't have anything for "custom easing functions"
<birtles> Rik, I think you said that was something you were interested in right?
<shans> that's P1 for me
<cabanier> yes
<cabanier> could be p2
<birtles> just out of curiousity, what do you have in mind--a scripted easing function?
<cabanier> a way of having more than 1 bezier describe the ease
<birtles> so it could be still declarative, but it needs more than one segment to the curve
<cabanier> so, a list of bezier function that are divided over the animation
<cabanier> correct
<birtles> ok, p2 for me
<shans> I'd like to see something a little more flexible even
<birtles> I'll add that to the list
<birtles> ok, well I just wanted to understand what we were talking about so I could vote
<shans> fair enough :)
<shans> I'm happy with that being P2 btw
<birtles> ok, great
<birtles> alright, next, "Animation target"
<birtles> re-using animations
<shans> so I'm trying to think about this in terms of animation API
<birtles> hmmm, this section is kind of weird
<shans> it's basically saying that an Animator can be used multiple times, right?
<birtles> yeah, that's right
<shans> P1 then
<cabanier> yes
<birtles> in SVG you can't re-use an animation, but in CSS you can
<cabanier> producing animations
<birtles> p1 for me too
<cabanier> I'd say p1 too
<birtles> the next req is something I haven't full formulated by I discussed it with Rik briefly at the F2F
<birtles> it allows you to set up an animation group
<birtles> where you have different sub-animations that target different child elements of the primary animation target
<cabanier> brian, what req is that?
<birtles> kind of like in the example code:
<birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/Requirements#Animation_target_2
<shans> some sort of template system for animations
<shans> (seems like)
<birtles> I think this section of "animation target" can be broken into two reqs
<birtles> 1) re-using animations
<cabanier> yes. I was thinking of doing it in the CSS keyframes
<birtles> 2) defining more complex animations that target more than one element of the target
<birtles> and we already voted P1 for (1)
<birtles> now I want to talk about (2)
<birtles> it's so you can define a "button" animation
<cabanier> (2) is definitely nice since you can describe a whole animation with multiple elements in 1 rule
<birtles> and it includes one animation that animates the rectangle background
<birtles> and one animation that targets the label
<birtles> and you target the whole "group" at the button
<shans> I think 2) is probably p3, but only because we'd want to look at all the templating efforts currently underway to see if one of them does it for us before designing anything
<birtles> and it uses some mechanism (like CSS selectors) to refer to the child elements
<cabanier> For me, it's not a must have, but it makes the syntax easier
<cabanier> and cuts down on CSS rules
<birtles> I guess a related point is with time containers
<cabanier>  (ie instead of 15 rules, you could have just 1)
<cabanier> yes. You wouldn't have to keep 15 in sync, just 1
<birtles> you might want to define the time container group elsewhere
<birtles> and have the group apply to another element (e.g. a frame-based animation that becomes a background)
<birtles> anyway, p2 for me
<cabanier> yes, p2 as well
<birtles> ok, "Integration"
<shans> I'm happy enough with p2, but I really do want to check out other templating efforts before doing anything
<birtles> yeah, good call
<birtles> first item, animations can target all animatable SVG attributes, and CSS properties whether they are in SVG or HTML
<birtles> p1 for me
<cabanier> That specification is already underway
<shans> p1
<cabanier> p1
<birtles> the CSS targetting SVG attributes is underway
<birtles> but SVG targeting CSS properties on HTML isn't yet
<birtles> ok, next, integration with <audio> and <video>
<cabanier> that is a p1
<birtles> yeah, p1 for me
<cabanier> well, at least audio is
<cabanier> not sure about video...
<shans> wait
<shans> what does that mean?
<birtles> it's not defined yet, but I think at a minimum it would include being able to synchronise animations with audio
<shans> ok, I can see there's a list
<cabanier> If you have an animation, you want a audio that is in complete sync
<birtles> whether it includes accounting for sync tolerance etc. is something to discuss later
<shans> but if we're doing this, do we want to go the other way too? keyframes can control audio/video seek pos?
<cabanier> I think that is separate
<shans> ok
<shans> well then p1 for me too
<birtles> yeah, we can define the scope of it later---sorry these requirements are very crisp
<birtles> s/are/aren't/
<cabanier> :-)
<birtles> they're quite vague---just a braindump
<birtles> ok, next, integration with subtitles
<shans> important to get this right
<shans> for a11y
<shans> so p0
<shans> :)
<cabanier> what does this mean?
<shans> actually we have some local expertise in that area, I can bounce any API ideas off them to make sure we're being sensible
<birtles> yeah, I'm just worried by the number of subtitle formats out there---looks like a minefield
<cabanier> yes, aren't there already groups working on this?
<shans> yeah
<cabanier> seems out of scope for animations
<shans> Silvia works out of the Sydney office, she's on those groups
<birtles> but I think it means we need some story for how animations could be synchronised with subtitles
<shans> yeah, we don't need to *define* subtitles, just make sure we interoperate
<birtles> e.g. an API to use
<shans> if you want, give me an AI to find out the current state of the art in subtitles (which formats need to be supported, etc.) and I can discuss next meeting
<birtles> thanks Shane
<birtles> ok, we'll come back to this
<birtles> ACTION: Shane to find out the current state of the art in subtitles for considering how to integrate with animation
<birtles> we don't have a trackbot here, but anyway
<shans> rofl :)
<birtles> next, integration with canvas, other web standards?
<birtles> WebGL?
<cabanier> hmm
<shans> can we p3 those maybe?
<birtles> we can cross them out if we don't want them
<cabanier> they are just scripted. no markup
<shans> add a section about "how to define support for <your favorite web technology>" to our spec
<cabanier> I'm sure people would like to have some support
<shans> they are just scripted, but e.g. controlling GL shader parameters from keyframe defs would make sense
<birtles> ok, the req is like Shane said
<birtles> "How to integrate with other specs"
<birtles> p3 for me
<shans> having a section on how to integrate is p1 for me
<cabanier> p2 for me
<shans> FULL HOUSE
<shans> no wait
<birtles> lol :)
<birtles> ok, next, "define how animations should be rendered in static situations"
<cabanier> shane?
<shans> hmm
<shans> Rik - the "no wait" was because full house isn't the correct term.
<cabanier> ah
<birtles> I guess the question is, how important is it to define this behaviour?
<birtles> for me, it's p2
<cabanier> p3
<shans> p3 for me too
<shans> I don't think it's something that's missed atm, right?
<birtles> no, the main area where it's becoming important is SVG in OpenType
<birtles> but I think they're going to define the behaviour there anyway
<birtles> so yeah, I'd be ok with p3 in that case
<birtles> ok, integration with HTML
<birtles> I guess the question here is, how important is it define the integration with HTML? Hmmm, these are sounding less and less like "requirements"
<shans> that first point isn't really relevant to the API at least, it's more something for SVG / HTML to nut out
<cabanier> I think whatever we come up with should be expressible in CSS
<shans> well a subset will be, but I suspect we'll end up defining features that don't (yet) have CSS markup
<shans> likewise for SVG
<birtles> yeah, there are a number of parties concerned about making CSS syntax too complicated
<shans> but this section to me feels like asking if we should try to encourage HTML to become a client of the API, like CSS and SVG will hopefully be
<shans> which I think is probably good to do, but not as a high priority
<birtles> right
<birtles> we don't really need to discuss that now
<birtles> let's skip this section
<birtles> it doesn't make much sense
<cabanier> OK
<shans> righto
<birtles> next, integration of SVG and CSS
<birtles> I think p1, we have to define that
<birtles> but *how* they integrate remains to be seen
<shans> we have to at least demonstrate a mapping of existing SVG / CSS behaviour to the new API
<shans> so yeah p1
<cabanier> isn't this also what Patrick's working on?
<birtles> not really
<cabanier> o wait, presentatiional attrs
<birtles> this is about how animations defined in SVG interact with animations defined in CSS
<birtles> how the properties line up etc.
<birtles> most importantly, what happens when both target the same property
<cabanier> so CSS anim + SMIL?
<shans> what's Patrick working on, out of interest?
<birtles> how to allow CSS Animations to target SVG attributes
<cabanier> have CSS animation/transitions apply to SVG elements
<shans> of right
<shans> s/of/oh/
<cabanier> he is not interested in SMIL
<cabanier> since they will not implement it
<birtles> yeah, I'm not sure about that
<cabanier> p3 for me as well
<birtles> if we create demand, he will implement it
<shans> so what I hope happens here is that we map CSS -> WebAnim, and SVG -> WebAnim (which, although we won't say this externally, means working out how to emulate SMIL's behaviour), and CSS <-> SVG interoperability will fall out of the semantics of the WebAnim API
<birtles> yeah, if the API is shared, it should be fairly cheap to add support for SVG animations
<cabanier> in the new world, they're one and the same
<shans> yep
<birtles> right
<cabanier> I'm worried that integrating with old SMIL will consume a lot of time
<shans> me too
<shans> we'll just have to see how it falls out
<birtles> hmmm, yeah
<birtles> well, SVG2 has a backwards compatibility requirement
<birtles> but I think we can simplify some things along the way
<cabanier> we can leave it blank for now
<birtles> and the SVG WG have already resolved to extend SVG Animations in various ways
<birtles> ok, accessibility
<birtles> I'm really not sure what this means
<shans> this could be something else I talk to our a11y folk about, if you want
<birtles> i.e. what are the actual requirements here?
<birtles> yeah, that would be great
<birtles> ok, next "API"
<cabanier> this is another complex topic..
<shans> heh
<cabanier> (=accessibility)
<cabanier> not the API :-)
<birtles> yeah, the API is a piece of cake :)
<cabanier> yeah, that one too! :_0
<birtles> well, we'll leave accessibility with Shane for now :)
<shans> what I'll do is mainly try to collect a wish list
<cabanier> API is p1 all the way
<shans> and then we can go through and prioritise that or something
<birtles> yeah, I think that would be really awesome if we can make animations created by script (using the API) accessible
<birtles> ok, thanks Shane
<shans> yeah I can't see anything in the API that would be lower than p1
<cabanier> the timeline API would be very cool but could be lower
<birtles> ok, great
<birtles> p1 across the board, except the timeline API
<birtles> is p2?
<cabanier> yes
<shans> (I'm a bit biased towards p1ing the timeline API too, because I think it will be quite easy with the approach I'm chamioning :))
<cabanier> if it's easy, p1
<birtles> well, p2 means we try our best to do it, but we're ok with putting it off until the next version if absolutely necessary
<shans> yeah, p2 covers it
<cabanier> p2 is fine then
<birtles> ok, error handling
<birtles> we should define it
<birtles> p1
<shans> p1
<cabanier> p1
<birtles> ok, tree surgery/liveness
<shans> p1 to "need to define"
<birtles> we should define it
<shans> we can work out what it should do later
<birtles> yep, p1
<birtles> right, this is the biggest problem with SVG Animations
<birtles> it's not defined so you just have to work out what makes sense
<birtles> alright, testing
<birtles> I think w3c already mandates this right
<cabanier> yes
<shans> gotta be p1 regardless
<cabanier> p1 too
<birtles> so, yeah, p1
<birtles> alright, prioritisation done!
<cabanier> not sure about the automated part
<birtles> any other requirements to add though?
<shans> w00!
<birtles> cabanier, yeah, I'd prefer them to be automated but we can have some manual ones too if necessary
<shans> I can't think of anything off the top of my head
<cabanier> about animation of paths.
<shans> but we can always revisit this list as more stuff comes up right?
<birtles> we'll make the requirement just to "have tests"
<cabanier> we can think of adding support for inverse kinematics
<birtles> shans, yeah
<cabanier> would be a p2/3
<shans> Rik, that would be pretty cool
<birtles> it would be very cool
<birtles> it's p3 for me though
<birtles> because I think the authoring tool can do it for now
<cabanier> more powerful than just path interpolation
<birtles> and export the result (as a series of transform animations etc.)
<shans> yeah
<cabanier> true, but it's pretty difficult to render
<cabanier> you get a lot of path segments
<shans> but anything that removes tools from the chain is a big win
<birtles> oh ok, I'm interested then
<cabanier> I'm OK with p3
<birtles> ok, p3 for now
<cabanier> or p2
<shans> me tpp
<shans> too
<cabanier> cool!
<shans> dammit can't type today
<birtles> shans, me too = p2? or p3?
<shans> p3
<birtles> ok, yeah sounds like something to add in a follow-up version
<birtles> unless there's a spec already out there we can integrate
<birtles> alright, next on the agenda...
<cabanier> not sure
<cabanier> I can look into it
<birtles> ok, thanks
<birtles> what time do you want to finish?
<shans> I don't mind
<cabanier> pretty soon
<birtles> ok, well both of the other topics probably take a while
<birtles> I think Shane, you wanted some more time for looking into the API / object primitives stuff?
<shans> yeah
<birtles> ok, do we have enough time to talk about synchronisation options then?
<shans> this is going to be a big discussion
<shans> I'd prefer to wait
<cabanier> I don't think we have quite enough
<cabanier> time
<birtles> yeah, ok, good
<birtles> well, that's it for today then I think
<cabanier> I will look into IK
<shans> I'll check out a11y
<birtles> cheers
<birtles> I'll add all those priorities to the requirements
<birtles> alright, thanks Rik, thanks Shane!
<shans> thanks Brian
<birtles> oh, next meeting!
<shans> mon/tue?
<cabanier> OK
<birtles> ok with me
<birtles> great, done
<shans> done
<cabanier> o wait
<cabanier> that's a holiday
<cabanier> I will be skiing that day
<birtles> nice :)
<cabanier> the next day?
<birtles> suits me
<shans> yeah
<birtles> maybe we can just have one meeting next week
<birtles> Tues/Wed
<cabanier> we can make the call after tuesday
<birtles> ok
<birtles> alright, thanks again
<cabanier> goodbye everyone!
<cabanier> (this time IRC worked fine!)
<shans> yay :)
<birtles> yeah, my hands are tired ;)
<birtles> (the regular breaks were kind of nice)
</pre>