Web Animations/Meetings/Meeting 7

From Effects Task Force

Time, location: 27 Feb 16:00 PST / 28 Feb 11:00 AEDT / 28 Feb 09:00 JST, #webanimations

Agenda

  1. Project timeline
  2. Animation sandwich priority
  3. Synchronization discussion
    • Synchronisation with script—Do we need synchronous events? How feasible are they? Do we need groups? etc.
      • Shane and Brian to look into feasibility / integration with DOM event model, RequestAnimationFrame etc.
    • Time Machine / Time as Artefact etc.—stepping back and designing declarative synchronisation first?
  4. API / Object primitives
    • Brian to propose alternative API without stacking so we can compare
  5. Accessibility - Shane

Resolutions

  • By the end of the work week in Tokyo (Mar 28-30) we want to reach a common and fairly concrete understanding on:
    • Sync (incl. time containers)
    • API primitives / base concepts
    • Addition
  • At Tokyo we will decide if we should present something at SVG Open 2012. If we do, we need to have an abstract by Apr 16.
  • For Hamburg (May 9) we will try to have a fairly concrete proposal covering the above topics plus an outline of the other features. Also we will have a presentation explaining the approach we have taken.

Actions

  • Shane to prepare a proposal about how addition might work.

Log

<shans_> hi Brian & Rik
<birtles> Hi Shane!
<birtles> cabanier, you free to meet?
<cabanier> Hi Brian
<birtles> Hi Rik!
<birtles> ok, shall we start?
<cabanier> yes, I'm good. I will have to leave 50min in though
<birtles> no problem, there's a lot on the agenda but I wasn't expecting to get through all of it
<birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings/Meeting_7
<birtles> 1) Project timeline
<birtles> 2) Animation sandwich priority
<birtles> 3) Synchronization discussion
<birtles> 4) API / Object primitives
<birtles> 5) Accessibility - Shane 
<birtles> I added (2) -- it's based on something that came up on the www-svg list
<birtles> which I think we need to talk about before the next SVG telcon
<birtles> anything else to add or re-order?
<cabanier> yes, Dirk wants to see that specified
<birtles> right
<shans_> nope, looks good
<shans_> just trying to read the email linked from (2)
<shans_> but I can do that later
<birtles> yeah, I'll try to summarise when we get to it
<birtles> so, let's start on the timeline
<cabanier> I think Dirk wants to talk about it during the SVG meeting
<cabanier> OK
<birtles> I guess it's best to work backwards
<birtles> so we have two fixed dates
<birtles> 1) Mar 28
<birtles> 2) May 9
<birtles> (1) is meeting in Tokyo
<birtles> (2) is the FXTF meeting
<birtles> we should decide what we want done by each of those milestones
<birtles> so, perhaps it's best to start with (2)
<birtles> what do you want to have ready for the FXTF?
<birtles> (in Hamburg)
<shans_> ideally, a concrete proposal with mappings back to CSS and SVG?
<shans_> I think an implementation by then might be too much
<cabanier> yes. API proposal + a good grasp on the model
<birtles> yeah, I agree
<birtles> I had originally hoped to get some prototype implementation but I think it's too much
<cabanier> it depends on how much we can get done on 1)
<cabanier> but it will be a lot of coding
<birtles> yeah, we could perhaps prototype a few features in JS
<shans_> we *could* do that, for sure
<cabanier> true
<birtles> like we already have a prototype of the state machine stuff in JS I think
<shans_> yes
<shans_> which reminds me
<shans_> I have permission to open source that
<shans_> I just need to push the big red button
<birtles> so, if we felt we needed to convince people about, e.g. time containers, we could perhaps mock that up in JS
<birtles> ooh!
<cabanier> what is the state machine?
<shans_> I'll try and get it released by the next meeting, Rik
<cabanier> OK!
<shans_> you can have a play with it directly. It's the demo I showed Brian back in Sydney
<birtles> ok, cool--well that's something we could demo at the F2F
<birtles> since that might be something most people aren't familiar with
<cabanier> ah. the extended transition spec
<shans_> yep
<birtles> but for now, I think we can resolve that we won't be expecting to have an implementation ready for Hamburg unless we get ahead of ourselves
<shans_> yeah
<birtles> so, what we are aiming for is a fairly detailed spec, covering most of the features
<birtles> ?
<birtles> (but probably with lots of questions still in it)
<cabanier> yes. sync model + APIs to control timeline
<shans_> well, I think there's some stuff that needs to be resolved
<shans_> namely that stuff :)
<cabanier> :-)
<shans_> and the rest can have big question marks
<birtles> of course, we also need to prepare a presentation outlining the approach we're taking, rationale, etc.
<shans_> yeah that'll be really important
<shans_> we need to be able to have a coherent message
<birtles> somewhere I had a list of what I thought were the three big issues that would impact the API... but I can't find it :(
<birtles> but I think sync model is one of them
<birtles> time containers was another
<birtles> and I can't remember the third :(
<birtles> but basically if we have those kind of fundamental features clear then that's a good base to build the other features on
<cabanier> was it the animator stack?
<birtles> yeah, I think it might have been---or more specifically "addition"
<birtles> oh, wait, those are different aren't they
<birtles> I think number 3 was "addition"
<birtles> which covers a lot of things--addition to self, addition to other animations, addition to base value etc.
<cabanier> addition is HARD
<birtles> yeah, that's why we need to think about it early
<cabanier> or postpone it
<shans_> some kinds are easier than others, but yeah it's going to be tricky to get addition right
<birtles> well, if we postpone it we need to have a story for how we can add it later
<birtles> so we don't shoot ourselves in the foot
<birtles> make an API that can't be extended to include it later
<birtles> anyway, we have a fairly vague idea of what we want for Hamburg,
<birtles> maybe we can start talking about what to aim for, for Tokyo
<birtles> is that 4 weeks away?
<shans_> give or take, yeah
<cabanier> yes
<cabanier> is Alex coming too?
<birtles> I think so right Shane?
<birtles> how about Vincent?
<cabanier> no, he can't make it
<shans_> pretty sure Alex will be there
<birtles> ok, so what should we aim to have ready before we meet--and what should we aim to do while we're together?
<shans_> actually he definitely will. He even has tickets :-D
<birtles> great! :)
<cabanier> I think we will continue what we're doing on the chats
<cabanier> but faster
<shans_> yeah
<shans_> I think we might have moved further in our sync and API discussions, but I suspect we won't have resolved our final approach by the meeting
<shans_> those are the two big things at the moment, right?
<birtles> Ok, well, we can make it our goal that by the end of the time together we come to a good understanding of what we want to do in three areas:
<birtles> 1) sync
<birtles> 2) API primitives / base concepts
<birtles> 3) addition
<birtles> (and if possible, time containers)
<birtles> does that sound right?
<birtles> any other goals?
<shans_> yes that sounds good
<cabanier> yes
<shans_> I think time containers == sync btw
<cabanier> I think so too
<shans_> or sync is a subset, or something
<birtles> yeah, that's right
<cabanier> we might want to cover object lifetime if there's time
<birtles> ok, well then, up until the meeting I guess we can just forge ahead with (1) and (2) and see how much progress we can make
<cabanier> sounds good
<birtles> cabanier, yeah, that's an important one
<birtles> I think object lifetime will come under (2) to some extent
<shans_> maybe we should start to talk about addition too, at least so we have some clearly defined requirements by the meeting?
<birtles> I was just about to say that :)
<birtles> are you volunteering to make a proposal? ;)
<shans_> I guess we should then ;-)
<shans_> uh, sure
<shans_> I can do that
<shans_> but it might be woefully incomplete
<birtles> that would be great!
<shans_> at least it'll be a start :)
<birtles> hey, that didn't stop me ;)
<cabanier> I will brush up on SMIL for that and see how it's different from flash
<shans_> OK, so ACTION for Shane to put up an initial proposal for addition
<birtles> great, thanks
<birtles> one other milestone which we *could* consider is SVG Open
<birtles> it's in September 11-14 in Zurich
<cabanier> we need an implementation by then
<shans_> yeah that would be interesting
<birtles> if we thought it was useful to present something there (even a workshop) then we need to get an abstract in fairly soon
<birtles> Apr 16 to be precise
<birtles> http://svgopen.org/2012/
<birtles> I guess we can talk about that in Tokyo
<cabanier> yes.
<shans_> yeah, maybe we can decide based on how far we get
<cabanier> and we can keep it vague
<cabanier> depending how far we get with an implementation, I can write a translation tool so we can create interesting content
<birtles> yeah, that's the strategy with abstracts isn't it :)
<birtles> yeah, that would be great
<birtles> ok, any other items you want to see on the timeline?
<birtles> other things we need to start thinking about?
<shans_> not at this stage
<cabanier> no
<birtles> ok, well let's move on to agenda item (2) then, Animation sandwich priority
<shans_> I think if we resolve those big 3 by end of March then we're going very well indeed
<birtles> ok, sounds good
<cabanier> I'm not sure we should tackle that one
<birtles> Dirk mailed svg-wg (and www-svg) about the priority of SMIL animations vs CSS
<birtles> http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0131.html
<birtles> the reason I want to bring it up
<birtles> is that it sounds like there's a push to get a hard-and-fast rule about which syntax has priority
<birtles> i.e. CSS applies over the top of SVG or vice versa
<birtles> and ideally it would be nice if we didn't have that rule
<birtles> in the future it would nice to have a generic rule for deciding priority
<birtles> that didn't depend on syntax used
<birtles> e.g. start time
<birtles> so that it doesn't matter if you define your animation with CSS, SVG or script
<shans_> yeah, I agree
<birtles> but it's a matter of timing here...
<shans_> I actually think the sandwich model is not the right one, though (i.e. we shouldn't use start time to indicate priority)
<birtles> I understand Dirk needs a guideline to work with
<birtles> right, I'm not so concerned about what the rule is
<shans_> yeah
<birtles> unless, the rule ends up being something like "specificity"
<birtles> in which case it probably is compatible with saying CSS or SVG wins
<birtles> it ties into the whole discussion on addition
<shans_> nah, I think it should be an explicit order in the Animation API
<shans_> hmm, which is probably also compatible with saying one will win
<birtles> I'm just afraid that we'll decide something this week about SVG vs CSS and then whatever rule we make, we have to add an exception "unless it is defined in SVG" or something like that
<cabanier> who is going to combine these models anyway?
<birtles> well we're trying to define a base for them to work off
<birtles> I think everyone wants a common base
<birtles> and ideally I think you should be able to move between CSS and script and SVG and not get surprising results
<shans_> I could definitely imagine e.g. defining a base CSS animation and a reactive SVG animation and wanting to combine them
<birtles> e.g. the animation stops overriding because I changed syntax
<birtles> yeah, I think you want, also, an animation defined entirely in CSS, and one defined entirely in script
<cabanier> I'm afraid this will snowball
<cabanier> you can do anything in script...
<birtles> and there should be some simple rules about how they play together
<birtles> I'm thinking of script that uses our API
<birtles> not generic animation script
<cabanier> so, that would be like CSS...
<birtles> i.e. uses Animator objects, not RequestAnimationFrame + callback
<cabanier> I thought we were extending the CSS animation stack so we can just say that we follow the css rules
<birtles> that doesn't address how to integrate with SVG
<birtles> (and I've also put up a counter-proposal because I'm not yet convinced we need a stack)
<cabanier> you mean SMIL?
<birtles> SVG animations (which is based on SMIL but not the same)
<shans_> this is what I hope we end up with
<shans_> an extra CSS property (something like animation-index: )
<shans_> plus an extra SVG attribute (maybe also animation-index)
<shans_> and that defines the stacking order
<shans_> obviously there needs to be a default order when multiple things have the same animation-index
<shans_> but in that case we can just say CSS beats SVG, or SVG beats CSS
<shans_> does that sound somewhat reasonable?
<birtles> what about script?
<shans_> well, same deal
<shans_> on the Animator you can set an animationIndex
<shans_> oh, and I guess you need sane default orders for script Animators too
<shans_> maybe CSS > SVG > script or something
<birtles> I mean, we don't really need to define the rule yet, but I'm just concerned that prioritising one syntax over another is not a great path forward
<shans_> (animationIndex could be 0 by default, so if you want script > CSS > SVG then you can set an animationIndex in script of 100)
<birtles> I can imagine scenarios where you have a CSS selector, with an 'animation-name' that points to an animation defined by SVG, that is modified by script
<shans_> what I'm saying is that even if we do prioi�ritise one syntax over another, there's ways out
<birtles> so I guess that's a CSS animation?
<birtles> ok, fair enough
<shans_> and that we probably want those ways out anyway
<birtles> that puts me at ease a bit
<birtles> well, I'm prepared to just trust that that's the case
<birtles> we can move on then
<birtles> it's just a shame this is happenning now
<birtles> I really wish it was 6 months later
<cabanier> what is a shame brian?
<birtles> after we'd had time to think through all the possibilities
<birtles> that we're probably going to make a rule about CSS or SVG winning
<cabanier> ah
<birtles> I mean it's coming up in the SVG telcon
<shans_> hey
<birtles> I'm pretty sure we could do a better job for the Web if we thought about animations wholistically
<birtles> rather than just on a syntax level
<shans_> I just heard that Dimitri Baranovski is coming to lunch today
<shans_> Alex invited him :)
<birtles> but we don't have time to do that by Friday :)
<birtles> oh cool!
<shans_> anything you want me to ask him?
<birtles> yeah, could you put forward the basic idea of CSS and SVG working off a script API
<birtles> and see what he thinks
<shans_> sure, will do
<birtles> and what features he would want in that API?
<shans_> Brian: I agree with you wholeheartedly (re: thinking about animations holistically)
<cabanier> yes, I think that is what we're doing 
<shans_> agreed
<birtles> thanks Shane
<cabanier> if not, we're going about it the wrong way
<shans_> yeah
<birtles> yeah, I think *we* are but I think that in order to make a quick decision, the SVG WG can't wait to consider all the possibilities
<birtles> I understand Dirk and other implementors need a guideline now
<cabanier> We might convince them to wait
<birtles> and once you have a guideline content authors start expecting that behaviour
<birtles> and then you can't change it without breaking content
<birtles> ok, well can anyone here join the telcon?
<cabanier> it can be left unspecified in the spec
<birtles> it's 2am my time I think and I don't have internet at home
<cabanier> I will be there
<birtles> well, perhaps you could just mention that concern Rik?
<cabanier> I will do so
<birtles> but we understand the need to have a guideline of course
<birtles> thanks Rik
<birtles> ok, well next topic then
<birtles> oh, only 6 minutes?
<shans_> in this particular case, I think we want explicit ordering as part of the API, and we want that exposed (later) to both CSS and SVG. In that environment a default ordering (where the explicit orderings don't disambiguate) is both important to define; and arbitrary. If you agree with that then I think there's no harm at all in them deciding on an ordering. On the other hand, if you want to trigger ordering implicitly based on properties like start time the
<shans_> could be a problem
<cabanier> sorry, yes
<shans_> (sorry, just restating what I was aiming to say above)
<birtles> shans_, gotcha
<birtles> yeah, it's that default ordering which I'd like to be generic
<birtles> well, we don't really have enough time for synchronisation / api
<birtles> I put some notes in each
<shans_> I can definitely give a 5 minute summary on a11y if you want
<birtles> shall we talk about accessibility then?
<birtles> great, please!
<shans_> ok
<shans_> so basically it all comes down to this:
<cabanier> Shane,maybe you should email a response to the mailing list...
<shans_> there's an object primitive that the a11y folks are defining called um Timed Text or something like that
<birtles> cabanier, I take it you have to go
<cabanier> yes
<shans_> which mailing list?
<birtles> oh, sorry Shane
<birtles> us 3 + Alex and Vincent?
<cabanier> www-svg
<shans_> Rik, you mean the ordering thing?
<shans_> I don't have a strong opinion
<shans_> except that it doesn't hurt us for an ordering to exist
<cabanier> in response to "Agenda request: Presentation attributes in animation sandwich model".
<shans_> do you want me to go on with a11y or we can do that later?
<birtles> I can send a quick note
<cabanier> otherwise, I will tell them about our concern and possible workaround
<birtles> I think Rik has to go
<shans_> ok, next time then
<birtles> sorry Shane
<birtles> I was really looking forward to that :(
<birtles> shall we meet again Thurs/Fri ?
<cabanier> Thursday is good
<shans_> suits me
<birtles> great, let's do that
<birtles> sorry, I took too long on the timeline / ordering stuff
<birtles> we'll get to accessibility, sync, etc. next time
<birtles> thanks guys!
<cabanier> no problem!
<cabanier> bye
<shans_> I'll respond to your comments in the meantime :)
<shans_> bye
<birtles> shans_, cheers :)
<birtles> see you!
Retrieved from "https://www.w3.org/Graphics/fx/wiki/index.php?title=Web_Animations/Meetings/Meeting_7&oldid=315"