[webkit-dev] Adding Web Animations to WebCore

[Brian Birtles]

(Sorry, the threading is going to be incorrect here. I just joined the list to follow up this thread.)

Hi,

I wanted to add a few brief comments about the status of Web Animations in response to some of the concerns raised recently.

Maciej wrote:

> * At least in its current form, it is overengineered and unusable. An animation API should focus on ease of use, not combining every conceivable animation concept ever invented.

I'd genuinely appreciate your help with regards to identifying specific concerns and unnecessary features. As for usability, I think the video we released shows it's not entirely unusable.[1]

If the spec seems long it's simply because it's explicitly specifying much of what is left unspecified in SVG and CSS. It's predominantly composed of features already implemented in CSS and SVG. The number of new features is fairly small.

That said, I think there are some parts of the API we can tighten up and possibly drop. If you have specific suggestions I would really value your comments at public-fx at w3.org (subject '[web-anim] ... ').

> * It hasn't even reached FPWD yet so it's not clear that the design is mature.

Agreed.

> * I don't see any evidence of broad cross-vendor support for this direction (though there might be some that I overlooked).

Apart from Google, Mozilla and Adobe are strongly behind it (all three are active editors). In fact it was initiated by Mozilla under Adobe's prompting and in response to discussion over the space of a year at various FXTF meetings with support at the time from Apple.

Opera and Microsoft have yet to make any concrete commitment but have not opposed it when presented with the idea.

Dean Jackson wrote:

> As well as Maciej's concerns, I'd like to add that we already have three non-interoperable animation technologies in WebKit (SMIL, CSS and rAF). I think we need to clean this up before adding any more complexity.

As I'm sure Dean is well aware, the primary purpose of this specification is to unify the SMIL and CSS models. In Gecko I anticipate replacing much of our SMIL implementation with this API as well as parts of CSS. I see implementing Web Animations as an opportunity to unify this code but you know your codebase best and how best to stage the development.

Elliott Sprehn wrote:

> I'd also like to object to this as the API is very complicated and doesn't seem incremental or like it fits with existing platform features.

It's very much based on the existing features of CSS and SVG. If there are specific features which are inconsistent then your comments are sincerely welcome at public-fx at w3.org.

> Also the naming of things is inconsistent and messy. Why are half the interfaces and properties  abbreviated and half of them not?

I agree that there is certainly some tidying up in order. In fact, in my opinion, quite a lot. Development stalled briefly whilst some of us had other duties to attend to but now we're back on deck and looking to get this into FPWD-ready shape by the end of the year so your feedback is very precious. For example, if you have a preference for abbreviated names or not, then by all means please send feedback to public-fx.

> This doesn't feel baked enough.

I tend to agree (just look at how many TODOs there still are).

It's obviously up to you to decide when is the right time to start implementing. In Doug's defence I'd say he is well aware of how much this is still in flux.


In summary I just want to acknowledge that there is still much work to be done on Web Animations but that it should start moving more quickly in the coming weeks. As a result, your feedback is particularly valuable at this time.

I also want to apologise if this caught anyone by surprise. We've been posting to public-fx but I realise that not many people monitor that list. I'll try to send a note to www-style in the coming days to alert anyone else who might be interested.

Best regards,

Brian Birtles

[1] http://brian.sol1.net/svg/2012/10/31/web-animations/