Mozilla's Brian Birtles on the new web standards that will enable developers to synchronise animations with video and audio, and provide scheduling, seeking, reversing and other features
Brian Birtles is currently working at Mozilla Japan, and he recently posted about a new development for animation for the web, called Web Animations. Within, he showcased a video providing examples of the technology's potential. It’s early days for Web Animations, but we asked Birtles about the reasoning behind the idea and what it means for existing web animation techniques.
.net: In what ways do you feel animation on the web currently falls short?
Birtles: I think the biggest one is synchronisation. With CSS, it's impossible to generate a new animation on-the-fly that synchronises with an already-running animation—and yet that's quite fundamental to application development. In fact, it's quite unpredictable when a CSS-based animation will begin at all. SVG makes it fairly easy to synchronise animations, but, at least in SVG 1.1, you can't synchronise with media such as video and audio.
In terms of features, you can't easily create a bouncing effect with either SVG or CSS due to the way easing functions are defined. Furthermore, CSS doesn't allow you to seek an animation or add together independent animations and SVG doesn't support reversing.
Furthermore, if you need to interact with animations via script it's very difficult. The interface for manipulating CSS (CSSOM) is still fairly clumsy in this area, and while SVG offers a few methods for this, many interactions are still completely undefined.
For purely scripted animations, we have interfaces like RequestAnimationFrame but that still leaves it up to the author to write their animation function in such a way that it is frame-rate independent, and it doesn't help with synchronising with, for example, CSS animations or videos.
.net: What's the basis behind your ideas, and what do they achieve?
Birtles: The main focus is unifying what is possible with CSS Animations, CSS Transitions and SVG Animations into a single model. The CSS technologies are widely used but quite limited whilst SVG animations provides a more sophisticated model but is much less widely used since it applies only to SVG. At the same time, we're also extending the model to address the limitations I described.
.net: Can you give any examples of how Web Animations could be utilised by designers and developers?
Birtles: In concrete terms, it should mean producing animated subtitles to overlay onto a video and that remain synchronised even when it is seeked or played in reverse becomes not only possible, but straightforward. It should mean that the sort of cartoons currently realised using Flash can be easily achieved with W3C standard technologies. It should mean a few less limitations on adding visual clues to an interface via animation.
For those developers who are prepared to write script, there is a lot of power in the model we're proposing that they can flex. For example, it is possible to provide custom animation functions so that the synchronisation and scheduling features can be used to animate literally anything, including HTML5 canvas, scroll-bars, and even audio.
Having a model that is common to CSS, SVG and script gives designers freedom to change approach as their application changes and re-use their experience despite a different syntax.
.net: More power and control is potentially great, but are we heading towards a point where CSS is becoming programming-oriented?
Birtles: What we're proposing is ultimately the underlying model for both CSS and SVG animations. You don't need to program in order to use it since everything will be mapped to CSS and SVG syntax.
That said, many people will continue to use script to produce animations and so we have an API so you can use Web Animations from script too. It means you can write synchronised, frame-rate independent, reversible animations with a single line of code. And you can interact with animations created in CSS or SVG using the same interface.
I think declarative approaches like CSS have a lot of power. There are many situations where script simply can't be used, for example, due to security restrictions. If you want to animate the glyphs in a font (using SVG-in-opentype) or the background of a page, you're going to want declarative animations there. And that's just the start; declarative approaches bring all sorts of other benefits in terms of editability, performance, accessibility, re-purposing and so on.
But one of the cornerstones on which HTML5 was based was the recognition that script is not going away. Script lets you realise new ideas without having to wait for spec writers and implementers to lay the path first.
.net: And what about people who argue CSS is now going far beyond 'presentation'? Does that even matter?
Birtles: The separation between presentation and content is interesting. There are some animations which are visual flourishes that clearly fit the category of presentation whilst other animations such as cartoons feel much more like content. Within the model we're trying to cater to both uses. It may be that authors use CSS for presentational flourishes and an angle-bracket syntax like SVG for content-like animations—but that's not required. That's probably a distinction that's best left to the author, and by providing a unified model we hope to give authors freedom to experiment with different approaches.