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:

• What happens to the underlying Style during a transition?
  • The specification requires that the computed style should return the intermediate transitioning values, but doesn't specify what value should be returned for the element.style.foo property during a transition
  • Testing on webkit reveals that this value is updated to the final value immediately, but it is masked by the animated value until the animation ends. It is not animated.
• How do you deal with subproperties that have different numbers of values?
  • 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.
• What happens when an element's -webkit-transition* properties are modified?
  • 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)
• Do CSS Transitions apply to SVG content?
  • dholbert asked about this since it could be quite complex to deal with interactions between SVG content that had both CSS Transitions and SMIL animations defined
  • I saw some statements that implied that they should work, but when I tested CSS transitions with some SVG content on WebKit, I couldn't get it to work. I talked with Dave Hyatt, who said that it should work. But apparently only a subset of SVG CSS properties were supported (not the ones I was testing), so he added support for a few more properties while we talked.
• 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)
• SMIL transitions are always 1:1. In other words, a given animation element specifies a single target element and attribute to be animated. By contrast, a CSS transition can specify that it applies to a property of 'all' (which means that any style property change will be animated), and a given transition definition can apply to any (or all) elements of a document (based on what elements are matched by the style selector)
  • Because of this, it's not feasible for CSS animations to be treated the same way that SMIL animations are treated (e.g. all animation definitions are added to a list of animations when a document is loaded/parsed). If we did that for CSS transitions, we could end up with thousands of elements in the animation list, and most of them would probably never be used.
  • The approach we'll most likely need to use for CSS transitions is to detect a change in a property that has a transition applied to it. At that point, we can dynamically create an animation that maps to a single element and property, and add it to the animation list. Then when the animation is finished, we should remove it from the animation list.

Interaction with SMIL Animations in SVG content

• In WebKit, CSS Transitions can apply to SVG content. This raises the question of how transitions and SVG animations should stack when they're both trying to animate the same property.
• Currently, the proposed CSS Transitions spec doesn't address this at all.
• It seems like it'd make the most sense to treat the transition as just another non-additive animation in the SMIL Sandwich Model. To elaborate, here are some relevant quotes from that model's description:
  • "Each additive animation adds its effect to the result of all sandwich layers below. A non-additive animation simply overrides the result of all lower sandwich layers."
  • "The animation first begun has lowest priority and the most recently begun animation has highest priority. When two animations start at the same moment in time, the activation order is resolved as follows: [...]")

Notes from 2008-10-30 Meeting

• Decisions:
  • Animated style should be stored in a special per-element rule node
  • This rule node fits right in the middle of the CSS cascade (overrides other style, but not !important styles)
  • We'll detect style-changes that require transitions inside of DidSetStyleContext()
  • DidSetStyleContext() will need to know whether it was called due to a "real" style change, or due to a style change from a transition/animation. This will hopefully prevent transitions/animations from triggering new transitions each time they update the style. :)
  • Initially, we won't support transitions on pseudo-elements (e.g. "first-letter")