We're hiring!

We're actively seeking designers and developers for all three of our locations.

CSS3 Transitions – Spicing Up DOM Changes

In one of the web projects I have been working on we have a handful of elements on the page change size when they were “toggled”. This was a simple add and remove of an active class (via jQuery’s addClass() and removeClass()) that caused our elements to snap open and closed. The user experience was good, nothing jarring. Just when we were about to move to another area of the app, we decided to smooth out the snapping of the UI to increase the user experience. We had two apparent options: a JavaScript animation library, or CSS3.

CSS3 Magic
CSS3 has introduced transitions into the web design world. Simply put, you can assign a “watcher” to an element and an property of the element (like a height on a certain selector), and when it changes it can smooth the transition between the states. Transitions are not support in Internet Explorer, so users will see the instantaneous jump between the two states of the CSS. Also, not all properties in your CSS can be animated. There is a lot to learn, so here are a few useful resources to get started with:

When do I use transitions?
While many JavaScript frameworks can provide a great animation framework on many browsers, CSS3 transitions don’t requires additional libraries to run. The big decision factor for the team was on how crucial the animations were. If the animation changed the layout, experience, or data on the page – we used the JavaScript tools to accomplish the same animation in all browsers. If the animation is just a pure visual polish to an already working display of the application, then we considered the use of transitions.

Note: Too much of anything is bad. Just because there are transitions doesn’t mean every layout change needs to have them applied to it.

Final Decision
We decided to go the CSS route. The reason behind the choice is that the snapping of the element size was perfectly acceptable, but the animation was just a little visual polish. We didn’t want to add more JavaScript and tests for the new code that only gave a simple visual glimmer. The majority or our users should be on devices that support CSS3, and for those that don’t have the support, their experience on the site should not be changed because of a minor difference in the animation of the elements for one widget.

Jared Sartin (34 Posts)

Web and mobile developer. Works in Ruby/RoR and JavaScript frameworks.

Strong passion for game development, UI design, and general UX.

This entry was posted in Web Apps and tagged , , . Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Brad Magnus
    Posted February 26, 2012 at 3:28 pm

    Very good explanation of your thought process. With all the different devices and browsers it’s sometimes hard to determine the best solution for determining the user experience. Thanks for the insight.

    • Jared Sartin
      Posted February 27, 2012 at 8:53 am

      It is hard, but I am happy to share insights on how we chose for our situation. Hopefully it helped if you were running into a similar experience!

      Thanks for the comment!