Web Animations/Meetings/Meeting 1

From Effects Task Force
Jump to: navigation, search

Time, location: 2 Feb 16:30 PST / 3 Feb 11:30 AEDT / 3 Feb 09:30 JST, #webanimations

Log

<birtles> Rik and Shane are you free?
<birtles> sorry, I mean cabanier and shans are you free?
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<shans> ready and willing
<birtles> cool, I think we just lost Rik though
<shans> looks like, yeah :(
-->| cabanier (cabanier@192.150.22.150) has joined #webanimations
<birtles> hey Rik, is your meeting done yet?
<cabanier> yes
<birtles> ok, so we can get started then
<cabanier> Is shane here too?
<shans> yep
<birtles> so a very quick background because I think Shane missed the last day or two of the F2F
<birtles> we decided to work on this Web Animations spec
<birtles> basically SVG 2 Animations = Web Animations + SVG specific bindings
<birtles> tentatively anyway
<birtles> Vincent is keen to get involved but he's not sure how much time he can commit
<birtles> I put up some very rough thoughts at http://www.w3.org/Graphics/fx/wiki/Web_Animations
<shans> ok, and we'd want to try and convince CSS to commit to something similar (CSS 4 Animations = Web Animations + CSS specific bindings)
<birtles> ideally, yes
<birtles> I'm not sure yet how likely that will be
<birtles> as a backup, when we list CSS properties already defined in CSS Animations we might say, "see CSS Animations here"
<birtles> but ideally I'd like to roll CSS Animations into the one spec
<birtles> very roughly speaking the goals are 2
<birtles> 1) Harmonise SVG and CSS Animations
<birtles> 2) Add extra capabilities to animation on the Web
<shans> nice
<birtles> what do you think roughly about that direction?
<cabanier> are you thinking of addressing issues with CSS animation as well?
<cabanier> ie the lack of synchronisation
<birtles> right, yes
<cabanier> great
<birtles> that requirements list at the moment is very draft
<shans> cabanier: I think the way to do that is (1) capture the current CSS semantics (where defined) so that CSS can move across to Web Animations without changing too significantly
<shans> and then (2) as part of the extra capabilities part make sure there are sufficient additional primitives that CSS has a clear improvement path
<cabanier> that sounds reasonable.
<shans> birtles: and the goal is to have something ready to present at the FXTF meeting in Hamburg, right?
<cabanier> I think everyone agrees that the current css animation spec is lacking
<birtles> right, that's another thing I want to talk about
<birtles> when we spoke at the F2F Vincent was keen for us to put together something concrete in a small group
<birtles> when I've raised the issue of harmonising in the past I've got a lot of pushback and Vincent thought it was just because people couldn't imagine it
<birtles> or assumed it was too hard
<birtles> so what I want to do is provide something concrete for people to discuss
<birtles> in terms of approach I want to avoid two two extremes of:
<birtles> a) design-by-committee
<birtles> b) doing everything behind closed doors and dumping a complete implementation and spec on the mailing list
<birtles> (which is kind of what happened with CSS Transitions and hence the incompatibilities with SVG)
<cabanier> birtles: I think when you say that you will merge the spec, people assumed that you will integrate SMIL to CSS. That's probably why there was pushback.
<birtles> so the idea is for just the 3~4 of us to work on something concrete before getting too much public feedback
<shans> that seems like a good approach
<cabanier> sounds good
<birtles> cabanier, right, yeah, that could be part of the problem
<cabanier> so, http://www.w3.org/Graphics/fx/wiki/Web_Animations is your current thinking?
<birtles> pretty much
<birtles> but it's very lacking
<birtles> for example, I'd like to add to that list all the features that are in both technologies
<birtles> so we can consider them one by one
<birtles> for example, additive animation
<birtles> it's not on that list
<birtles> but it's in SVG
<birtles> we should consider, do we want this in CSS?
<shans> from a CSS perspective, additive animation has been dismissed as "too hard"
<birtles> and if so, is the way SVG doing it good?
<shans> personally, I think that's wrong
<birtles> right, so for all those features I want to consider (a) do we want it at all, (b) do we want it in CSS, (c) how do we want to do it (i.e. is the way we're currently doing it good)
<shans> having a clear spec with proven useful behaviours backed by a simple declarative description would go a long way towards redressing that
<shans> ok, that makes sense
<birtles> so I guess that's my next action is to tidy up that Wiki by adding in all those features
<birtles> but I hope you both feel free to add requirements there too
<birtles> I know Adobe have hit a lot of hurdles with the current offerings of animation on the Web
<cabanier> yes.
<birtles> so obviously that's something we want to address
<birtles> the spec isn't just about harmonisation but also about adding functionality that's needed
<birtles> like the state machine stuff which I think is useful
<cabanier> In my investigations, we really only need synchronisation
<birtles> ok, the state machine stuff is probably more for UI design
<birtles> cabanier, are you mostly producing non-interactive animations?
<cabanier> and the ability to do put/remove items in the dom (through 'display:none/block' or other means)
<cabanier> no, even this is also for interactive ones
<cabanier> s/even/
<birtles> ahh, ok
<birtles> shans, did you manage to get the state machine spec into a Google doc yet?
<shans> yes, it's here: https://docs.google.com/document/d/10dxJFh__p6HA9s6Y0nxnqhXwAXN7qSxKK6MjOvN1FhY/edit?hl=en_US
<birtles> cheers
<cabanier> thanks!
<shans> there's still one section missing, and the bits I added are a little rough
<shans> but I'll keep polishing it :)
<shans> so the thing about the state machine stuff is it's in that cloudy area of stuff that *can* be managed by javascript
<shans> but, like everything else in this area, the experience is much better if it *isn't*
<birtles> right, I was thinking about that
<birtles> there is the possibility for us to limit this spec to just non-interactive features
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
<shans> so we need to work out whether or not the cost (in terms of complexity and additional code) is worth the benefit
<birtles> I guess we should wait for Rik to come back
<shans> yep
<shans> I'll replay my previous comment when he does
-->| cabanier (cabanier@192.150.22.150) has joined #webanimations
<shans> cabanier: we waited for you :)
<cabanier> :-)
<shans> so we need to work out whether or not the cost (in terms of complexity and additional code) is worth the benefit
<cabanier> I'm reading your spec
<birtles> we don't have to decide on it today but it raises the bigger question of whether or not we want to limit the spec to just non-interactive features
<shans> birtles: personally, I'd argue that the interactive features this sort of thing enables add a lot of power to the platform, and don't cost much in terms of complexity or code
<birtles> what I mean is that, for interactive stuff you *could* just say, "use script"
<cabanier> correct
<shans> what complexity is added is manageable too, in the sense that it doesn't pollute non-interactive primitives
<birtles> I'm inclined to agree, but we had this discussion with regards to features such as supporting DOM 3 Key identifiers
<shans> but yes, this is true, and if (as I hope) we decide to include interactive features then that decision needs to be backed up with solid reasoning
<birtles> Vincent would like us to add that (to augment what we already have in accessKey) but I raised the question, why not just use script for that?
<shans> oh, two more things: (1) I think that document is a proposal, not a spec. It's a little loose to be a spec :) (2) by hopefully next friday I'll have the demo publicly available too.
<cabanier> I have to do some research on dom 3 key identifiers
<birtles> ok cool
<birtles> I have to think a bit more about how we approach interactive features
<shans> yeah I'm afraid I don't know much about them either
<cabanier> I'm more familiar with the flash world where there are almost no interactive features
<cabanier> everything is in script
<birtles> animations have to be interactive via script, but whether we also support interactivity in a declarative way is a different question
<birtles> I think Vincent was keen for it because it makes authoring simpler
<cabanier> Vincent wants it to be declarative?
<birtles> Vincent was the one asking for support for DOM 3 Key identifiers
<cabanier> ah. OK
<birtles> well, we can list the interactive features for now, and prioritise them later
<birtles> I think the next step is to make up a more complete requirements list
<birtles> but I wanted to raise the question of syntax
<birtles> one of the goals I've listed is to try to maintain backwards compatibility with SVG Animations and CSS Animations
<birtles> that involves supporting both an element and CSS syntax
<birtles> like we do for Filter Effects
<birtles> what do you think about that?
<shans> not necessarily - it's also possible that we define Web Animations purely as an API
<shans> and demonstrate a mapping from CSS syntax to the API
<shans> (likewise with SVG syntax)
<cabanier> SVG animations (SMIL) too?
<shans> yeah
<birtles> ok, I'm having trouble imagining that
<cabanier> That would be very nice to have
<birtles> what do you mean by API? a scripting API?
<birtles> or a set of primitive concepts like SMIL?
<shans> so for example, we know that transitions (1) apply on change of property state (2) are simple linear interpolations and (3) need to be instantaneously cancellable and have current state recoverable
<shans> birtles: sorry for my ignorance here - isn't there an API layer exposed by the w3c that sits below scripting but allows for being exposed to scripting?
<shans> the IDL stuff?
<birtles> there's WebIDL
<shans> that might be it
<birtles> but I understood that as an abstract interface definition
<shans> basically, I'm imagining Web Animations as a box that CSS and SVG sit on top of
<birtles> it basically equates to a scripting API
<shans> when CSS wants to expose an animation primitive, it (1) defines a syntax for that, and (2) defines how the syntax maps to API calls
<shans> likewise with SVG
<birtles> ok, bear with me, I'm still having trouble imagining it
<shans> it might be easier if I write this up with pictures :-)
<shans> but, take transitions
<birtles> yeah, probably :)
<shans> so we know the CSS events that generate a transition. That's a CSS thing.
<shans> and we can describe the creation of an animation in terms of a hypothetical Web Animation API
<shans> and we know that in order to support CSS transitions as they are currently, this animation must have certain capabilities
<shans> (1) it must be able to mutate the DOM in specific ways
<shans> (2) the current state must be queryable
<shans> (3) it needs to be cancellable
<shans> so that guides us in generating that API
<shans> and the result is a black box that can replace the existing CSS-specific mechanisms for animation - AND the SVG-specific mechanisms - AND provide a nice script interface too
<birtles> I definitely am interested in the API
<birtles> I'm just still processing this
<cabanier> Do you envision that there is a way to get an animation 'object' from a DOM Element?
<cabanier> that has these APIs?
<shans> or on a higher level, we have now unified CSS and SVG animation with a common mechanism while still allowing both groups autonomy in defining future specification directions and in choosing which Web Animation capabilities to incorporate.
<shans> cabanier: absolutely, yeah
<cabanier> OK. makes sense, you don't want to go to the CSSOM because those just define the style (and don't actually 'run')
<shans> also we have a mechanism for exposing capabilities directly through javascript
<birtles> hmm, I like it
<shans> which will interoperate with both the CSS and SVG animations
<shans> cabanier: well it would be up to the CSSWG as a whole to decide what they want to expose through the CSSOM
|<-- cabanier has left irc.w3.org:6665 (Connection reset by peer)
-->| cabanier (cabanier@192.150.22.150) has joined #webanimations
<birtles> wb
<cabanier> I like that too. I assume that will be API's for callback at certain points in time ie when transition/animation is at 50%, call this js function
<shans> cabanier: repeating last comment assuming you didn't see it
<shans> member:cabanier: well it would be up to the CSSWG as a whole to decide what they want to expose through the CSSOM
<birtles> I need to think it through a bit more. For example, in SVG Animations, order of addition is based (among other things) on the order of animation elements within the document. So if "animations" are not necessarily tied to document elements then we'd need to define things a bit differently.
<birtles> that's fine but I just want to think through if there are any things that would get it the way of following this approach
<shans> it would be a matter of defining an order of addition resolution in the API, then making sure that our mapping of SVG primitives to the API preserves the SVG view for animations defined entirely in SVG
<birtles> yeah, ok
<birtles> this is good
<birtles> I like this approach in principle but I want to chew it over a bit more
<shans> absolutely
<birtles> I have to more things I want to discuss:
<birtles> a) relationship to SMIL
<birtles> b) next steps
<birtles> do you both still have time?
<shans> yep, I'm good for at least 15
<cabanier> I have to leave in a couple of minutes
<birtles> ok, in that case, when are you free to meet next
<birtles> same time next week?
<birtles> or before?
<shans> maybe before so we can resolve those two questions?
<cabanier> that works. Tomorrow is open for me as well.
<shans> I can't easily do tomorrow
<birtles> tomorrow is saturday is Shane and I :)
<cabanier> :-)
<birtles> s/is Shane/for Shane/
<shans> what about Monday/Tueday?
<shans> same time
<shans> (monday for cabanier, tuesday for birtles + I)
<birtles> yep
<cabanier> that works. 4pm pst?
<cabanier> or 4:30
<birtles> 4pm is better if you're free
<cabanier> yes
<shans> 4pm
<birtles> great, thanks very much!
<birtles> I'll try to add some more to the wiki before then
<shans> awesome :)
<birtles> Feel free to edit away
<cabanier> OK. I will be there and read up on shane's and Brian's document
<shans> oh birtles want me to move the proposal to the wiki?
<birtles> that'd be great
<birtles> thanks Shane!
<shans> ok, I'll do that and finish / polish it
<birtles> great, thanks guys!
<shans> thanks brian :)
<cabanier> yes, thanks! talk to you on Monday/Tuesday