Covering the Implication and Basics of CSS Animation

Posted: May 04, 2009 Comments(8)

Over the past few months, I’ve been embracing progressive enhancement on a new(er) level. I’ve been using CSS3 to make my life easier, leaving other browsers in the dust with the extra touches. I’ve lost all interest in making sure a design looks equally sophisticated in substandard browsers, and instead opted to leave that last column in my table left aligned instead of making the table a bit easier to read with right justification.

Of course I still support IE, and I don’t want to bring that up for debate at this time. That poor horse has been long gone for quite a while, so we can all put our sticks down for a bit. I have, however, taken a more aggressive personal stance in my lack of attention to detail when it comes to that browser family.

A tweet by Jeffrey Zeldman really got me hooked to the prospect of further adoption of CSS3:

When all browsers except IE support CSS3, it will test the limits of progressive enhancement as a design philosophy.

With my further embrace of and focus on CSS3 came an increased interest in other bleeding edge techniques in Web design, primarily CSS animation.

Does CSS animation belong?

One of the ways in which I’ve been trying to raise the overall comprehensiveness of my projects is incorporating CSS animation where it may enhance the experience of a particular design. Animation in CSS has, from time to time, been a hot topic in Web design. Does animation belong in CSS? Does it constitute behavioral modification to the document, and therefore find its proper place through JavaScript? Is animation technically behavior?

Trying to classify the true placement of animation has proven to be a personal challenge to me. I can see both sides of the argument. I agree that animation can be correctly implemented through JavaScript, as has been done for some time. On the other side of my personal coin, I see that animation is more of a visual stimulus as opposed to direct behavioral change (e.g. updating the DOM with data received via AJAX).

The basics of CSS animation

As with all new technologies, you should take a minute to familiarize yourself with implementation as well as implication to make a more educated (and therefore accurate) decision to (not) use it.

The WebKit team provided a very nice write up upon the release of a nightly build that supports CSS animation. In the post, an overview of animation with CSS is provided, as well as a bit of documentation and example.

The WebKit implementation of CSS animation has a bit of a learning curve, but once you decipher how it works, it’s quite elegant (in my opinion). Applying a CSS animation comes in two steps. You’ll first designate your style as you would normally, defining any properties you’d like, with the addition of something new: -webkit-transition.

-webkit-transition is actually shorthand for three transition properties:

  • transition-property: The property to which the animation will be applied
  • transition-duration: The length of time the transition will last
  • transition-timing-function: Possibly better explained as the easing method you’d like to use

With these three properties, you’re provided a set of tools that can directly affect the richness of your designs, bringing the level of interaction up a notch or two. To make things even more elaborate, the WebKit team has also included support for comma delimited transition declarations, allowing you to animate multiple values using a single property declaration.

A finished implementation of WebKit CSS animation may look something like this:

div.message a.dismiss {
  opacity:0.2;
  -webkit-transition:opacity 0.3s ease-in-out;
}

div.message a.dismiss:hover {
  opacity:1;
}

If you’re using a recent build of WebKit that supports CSS animation, check out the example.

CSS animation can have dramatic affect on your designs, especially in Web application enahcements. Jonathan Snook recently published a screencast outlining his use of CSS animations while playing with Titanium, a platform I’m actively researching as well.

Jonathan’s use of CSS animation in his screencast really brings its potential to the surface. With animations such as the combination of scale and opacity to achieve stellar effects really helps to make CSS animations shine.

What should control animation?

Truly classifying CSS animation has been a personal challenge for me as a designer; what are your thoughts? Do you feel that animation belongs in the realm of style or behavior? Do you feel animation is something else entirely? Now that an option beyond JavaScript has surfaced, did that change your opinion? Do you see animation in CSS being continually adopted on a more consistent level when it comes to adding ‘that little something extra’ for those using an applicable browser?

Get my newsletter

Receive periodic updates right in the mail!
  • This field is for validation purposes and should be left unchanged.

Comments

  1. For me, it’s a non-issue until more browsers support CSS animation. And, even if they never did, wouldn’t bother me one bit. To me, it just makes more sense handled via JavaScript. Take ActionScript for instance — The reason it arose is because there was a need for more robust / granular control. That’s why animations written into XAML (for Silverlight, etc) make me shudder — Maintenance nightmare.

    Animations in markup, or in CSS for that matter, seem like using dynamic font-tags. Again, just my opinion. I’d rather script against animations than make them declarative. Especially because you can control any number of things on-the-fly, rather than use pre-defined easing / transitions.

    Then again, having simple (some might say wimpy) effects left up to CSS isn’t an altogether bad thing. The eye candy will work with JS disabled, and it lets designers add niceties without getting their hands dirty with JavaScript.

    In summation: I’d rather program, than style animations. 🙂

  2. I see transitions/animations as neither styles nor behaviors, but as effects (or you could also argue that an effect is the result of style and behavior combined).

    I’ve used both CSS and JavaScript to handle effects, depending on the effect and on the audience. Generally though, I’ll stick with JavaScript. Not because I’m against using CSS (as I would actually love to), but because I’d rather them be seen by a wider audience and not just Safari users.

  3. @Nathan Smith: Very well put! I really like your position on the subject and I’ve got to admit that’s where I was leaning. I hadn’t, however, made the connection between the similar inclusion with other technologies such as Silverlight…

    I also hadn’t made the relation to dynamic font-tags, but I can see your point there as well.

    @Elliot Swan: Very interesting point. I like that you’ve included a new term into the mix, as it’s just the thing I was having a bit of trouble with defining. I definitely agree in sticking with JavaScript to increase audience reception significantly.

    Thank you both so much for your thoughts!

  4. As far as seperation of Content, Presentation and Behaviour is concerned, the transitions / effects whatever we call it are a part of the behaviour of the page and it definitely should be controlled using JS. The level of seperation converges, when there are lot more stuff like this in CSS, which could come in the future. Let us clarify the scope of each !

Leave a Reply

Your email address will not be published.