CSS Transitions

CSS Transitions

CSS transitions are a CSS extension proposed by webkit to enable simple implicit transitions that animate CSS properties from one value to another.

Resources

• CSS Transitions Spec
• Bug 435441 - Implement Webkit's CSS Transitions proposal

Summary

The basic concept of CSS transitions is that you declare that certain CSS properties should be animated from the base value to the final value whenever they change. There are many different triggers that could cause the property to animate:

• a state change (e.g. :hover) causes the property value to change
• a user explicitly changes the style property via the DOM
  • element.style.PropertyName=newvalue
• user applies a new 'class' attribute to the element that results in a different value for the css property
  • this.setAttribute('class', "foo"))
• Modification of the actual style declaration
  • document.styleSheets[0].cssRules[0].style.width=...
• Probably others

The common point in all of these examples is that any time the computed style for an element changes, we need to detect that and start an animation from the old value of that property to the new value of that property.

In addition, while an element is in the middle of a transition, querying the computed style for that property should return the intermediate animating value (i.e. the computed value should be animated, not just the presentation)

Requirements

Here's my attempt to map out a set of requirements to implement this feature in Mozilla:

• We need a way to detect when a style change occurs so that we can start an animation
  • But we need to ensure that style changes caused by active animations don't trigger new animations.
• Computed style value must be updated during the animation
• After an animation has completed, the property value should remain at the final animation value
• If a new transition is started in the middle of an existing transition, it should use the current intermediate animating value as the starting point and transition to the new value (this is unspecified at the moment, but matches webkit's implementation)

Under-specified Behavior

Some things are not specified well in the CSS Transitions spec, so I've had to look at webkit's behavior for the intended behavior (or ask Dave Hyatt in some cases). The following are some of my findings:

• If the sub-properties are specified separately but there are unequal values specified, they should be handled in the same way that Multiple Backgrounds are handled in CSS3
  • That spec doesn't really address how to handle values of 'inherit' in combination with the 'jagged array' issue, but webkit's implementation treats it as follows: #parent{-webkit-transition-property: opacity, width;} #child{-webkit-transition-property:inherit;-webkit-transition-duration:1s;} will result in #child having two transitions (opacity 1s, and width 1s). In other words, the number of values inherited from the parent is used in determining the total number of transitions.
• If an element's -webkit-transition-* properties are changed (e.g. by dynamically changing the 'class' attribute such that a new set of style rules apply to it), the new style should be used to determine which properties should have active transitions (previous versions of webkit actually used the old style, but at some point the behavior was switched to use the new style's transition definitions)
• webkit does not support any shorthand properties for -webkit-transition-property
• When animating to or from 'auto' (e.g. for the 'width' property), webkit animates, but treats 'auto' as 0 (in other words, if you don't have a transition active for width, it would end up at a different value than if a transition is active for width. This is clearly a bug). When changing the property to a percentage (e.g. width:50%), webkit does not animate at all, it just updates the value immediately to the new value.

Comparison with SMIL animations

It would be very nice if we could share as much code as possible between the CSS Transitions feature and SMIL animation. dholbert already has a patch to animate CSS with SMIL described at SVG:SMIL+CSS. Here I'll list a few thoughts about how SMIL animation and CSS transitions compare (disclaimer: I have only read through the SMIL animation spec quickly, so I might not have a full understanding of the details of SMIL animation)

• Animation triggers are significantly different between SMIL animation and CSS transitions
  • SMIL animations are triggered by external events such as a mouse click or an elapsed time, etc.
  • As mentioned above, CSS Transitions are implicit animations. The animation is only caused by an event indirectly insofar as that event causes the style property to change. (This adds a lot of complexity since the transition will need to animate the property from the old value to the new value, but we don't want those style changes to start a new animation).
• SMIL animation is not by default a permanent change. After a SMIL animation is finished, the animating value is removed and the base (original) value is allowed to 'show through' again. This is different than CSS Transitions since CSS Transitions is a simple animation from one base value to a new base value.
  • I know that SMIL animations can 'freeze' the animation after it is finished, but this seem like a slightly different concept
    • After a CSS Transition is finished, I think the final value should become the new base value, and the override style should be cleared. For a SMIL animation, a frozen animation would simply result in the override style value being maintained indefinitely rather than changing the base value
• It seems that -webkit-transition-function could be mapped fairly easily into SMIL animation's calcMode with values of 'linear' and 'spline'
  • We would just have to map the non-linear CSS keywords (e.g. ease-out, ease-in, etc) to a set of cubic bezier control points.
• Both specs treat a negative start time (called 'delay' in CSS transitions) in the same way (e.g. start the animation immediately but act as if you had started in the past)