Weston Ruter

The WebKit team has been developing some cutting-edge proposals to extend CSS with the ability to do declarative animations and other effects. This ability is key to maintaining the three-fold separation of HTML content, CSS presentation, and JavaScript behavior. Animation effects on the Web today are accomplished with JavaScript code which repeatedly changes an element's style at a certain interval in order to create an animated effect. This practice, however, violates the separation between presentation and behavior because the animation behaviors are directly changing the document's presentation (i.e. modifying the style property). Ideally, all of the animation triggers and presentation states would be declared in CSS. And this is exactly what the WebKit team has proposed in its CSS Transitions specification.

Since it's a new WebKit proposal, however, CSS Transitions has only been implemented in WebKit-based browsers like Safari and Chrome. While a enhancement bug has been filed to add CSS Transitions to Mozilla, it isn't likely going to land in the near future; likewise, support in MSIE may not even land in the distant future. Nevertheless, declarative animation in CSS is still an attractive solution, and I wanted to use the technology today. I therefore developed a prototype script (raw) which implements a subset of CSS Transitions via jQuery Animation (inspired by Chris Schneider's CSS Effects powered by mootools).

This implementation requires a binding language such as Mozilla's XBL or MSIE's DHTML Behaviors. Because of this, the script works in Firefox 2, Firefox 3, and MSIE 7 (IE 6 is not supported, but it does have limited functionality); in WebKit-based browsers the script does nothing since CSS Transitions are supported natively. Opera is not supported because it has no binding language. Why is a binding language required? The script parses the stylesheet rules looking for transition-* properties, and when it finds one, it adds a binding to that style rule so that when the rule gets applied, the binding's code is executed on each of the newly selected elements. This enables transitions to get triggered when a class name is changed. The binding code knows the transition style properties which were defined in its containing style rule, so when it gets executed it transitions the elements' styles from the previously matched style rule to the styles defined in the newly matched style rule. Each of these style rules I'm calling transition states.

Now, as I already mentioned, this script implements a functional subset of CSS Transitions. It is important to remember and to follow the following restrictions:

1. Due in part to a bug in XBL which prevents a binding's destructor from being called, only one transition state (style rule) may be applied at a time, thus transitioned properties may not be cascaded.

2. Additionally, all of the style properties specified by transition-property must be specified in each transition state (the all keyword is not currently supported).

3. XBL and HTC bindings cannot be dynamically created on the client (except in Firefox 3.1), so a server-side script is required to generate the necessary bindings. A provided PHP script demonstrates what the server-side script must generate. The client by default expects this file to be called “bindings.php” and located in the same directory as the JS file. This path and filename and may be overridden by setting a global variable cssTransitionsBindingURL before the inclusion of the script in the HTML page.

4. In order to prevent a flash of unbound content in Firefox (all of the transitioned elements will flicker when the XBL bindings get applied; cf. FOUC), it is best to include the script in the head of the page along with jQuery and any dependent jQuery plugins, such as jQuery Color Animations (even though inclusion in the head is not the best practice for performance).

5. Since the CSS specification requires that parsers ignore any unrecognized properties, as already mentioned, the script loads each of the referenced stylesheets and re-parses them for rules containing transition-* properties; IE doesn't allow you to get the text content of a style element so all stylesheets containing CSS Transitions must be referenced via link elements, and the stylesheets must be accessible without violating the same-origin policy (since they are loaded via XMLHttpRequest).

6. Furthermore, since the transition-initializing bindings should only be added to rules which are actually transition states, for performance reasons this implementation requires that a comment /*@transition-rule@*/ be added to each transition rule.

7. IE has difficulty applying bindings in rules with selectors like “#foo.baz #bar” (where the baz class name gets added or removed): the binding does not get fired on #bar unless a DOM mutation happens on that element. This mutation can be accomplished by doing something like this:

   $('#foo').addClass('baz');
   if(jQuery.browser.msie)
       $('#foo #bar').addClass('temp-ie-class').removeClass('temp-ie-class');

8. Likewise, a similar workaround was built into the script to support :hover selectors for transition rules in IE. If another element is dynamically added to the page after the DOM is loaded, you must call cssTransitions.refreshDOMForMSIE(). Currently neither the :active nor :target pseudo classes are working in IE for transition rules.

See a lightweight example and then see it in production at ReBath Oregon, which is the site for which I initially developed this implementation at Shepherd Interactive.

Download source code at: http://shepherd-interactive.googlecode.com/svn/trunk/jquery-css-transitions/

Unimplemented Features and To-do Items

• Implement transition-timing-function property (currently only the default ease is supported).
• Implement transition shorthand property.
• Allow transition-property:all.
• Allow different transition-durations for each transition state.
• Add support for :active (in IE) and :focus.
• Implement Transition Events.