CSS Transitions Level 2

Status: ED
Work Status: Exploring
Shortname: css-transitions-2
Level: 2
Group: csswg
ED: http://dev.w3.org/csswg/css-transitions-2/
Editor: L. David Baron, Mozilla, dbaron@dbaron.org
Issue Tracking: Bugzilla bugs for all levels https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transitions&resolution=---
Abstract: CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration.
Ignored Terms: translate, rotate, scale
urlPrefix: https://w3c.github.io/web-animations/; type: interface; spec: web-animations
    text: Animation
urlPrefix: https://w3c.github.io/web-animations/; type: dfn; spec: web-animations
    text: animation
    text: animation type
    text: global animation list
    text: idle play state

Delta specification

This is a delta specification, meaning that it currently contains only the differences from CSS Transitions Level 1 [[!CSS3-TRANSITIONS]]. Once the Level 1 specification is closer to complete, it will be merged with the additions here into a complete level 2 specification.

# Starting of transitions # {#starting} Associated with each top-level browsing context is a current transition generation that is incremented on each style change event. Each time a new transition is generated, the current value of the (already incremented) current transition generation is stored as the transition's transition generation. ## The transition property name ## {#transition-property-name} Although the 'transition-property' may specify shorthand properties and the ''all'' keyword, individual transitions are generated for each longhand sub-property that is animatable. The expanded transition property name of a transition is the name of the longhand sub-property for which the transition was generated (e.g. 'border-left-width'). ## Owning element ## {#owning-element-section} The owning element of a transition refers to the element or pseudo-element to which the 'transition-property' property was applied that generated the animation. If a transition was generated directly by script (e.g. using the {{CSSTransition}} constructor) then it has no owning element. If a transition generated using the markup defined in this specification is later disassociated from that markup because it is cancelled or replaced by a newer transition, the animation is disassociated from its owning element (that is, it has no owning element from that point forwards). Issue: Define the above more precisely once we rewrite firing of transitions in terms of Web Animations concepts (specifically when we spell out when we cancel an animation). ## Animation composite order ## {#animation-composite-order} Animations generated from the markup and interfaces (e.g. the {{CSSTransition}} constructor) defined in this specification have an animation type of ‘CSS Transition’. CSS Transitions have an earlier composite order that CSS Animations and animations without a specific animation type. Within the set of CSS Transitions, two animations A and B are sorted in composite order (first to last) as follows: 1. If neither A nor B has an owning element, sort based on their relative position in the global animation list. 1. Otherwise, if only one of A or B has an owning element, let the animation with an owning element sort first. 1. Otherwise, if the owning element of A and B differs, sort A and B by tree order of their corresponding owning elements. With regard to pseudo-elements, the sort order is as follows: * element * ::before * ::after * element children 1. Otherwise, if A and B have different transition generation values, sort by their corresponding transition generation in ascending order. 1. Otherwise, sort A and B in ascending order by the Unicode codepoints that make up the expanded transition property name of each transition (i.e. without attempting case conversion and such that ‘-moz-column-width’ sorts before ‘column-width’). Transitions generated using the markup defined in this specification are not added to the global animation list when they are created. Instead, these animations are appended to the global animation list at the first moment when they transition out of the idle play state after being disassociated from their owning element. Transitions that have been disassociated from their owning element but are still idle do not have a defined composite order. Note, this behavior relies on the fact that disassociating a transition from its owning element always causes it to enter (or remain) in the idle play state. Transitions created using the {{CSSTransition}} constructor are appended to the global animation list at the moment they are constructed. # Transition Events # {#transition-events} ## Types of TransitionEvent ## {#transition-event-types}

The additional types of transition events that can occur are:

The transitionstart event occurs when a transition is started (i.e., when it is added to the set of running transitions).
The transitioncancel event occurs when a transition is cancelled.
# DOM Interfaces # {#interface-dom} ## The CSSTransition interface ## {#the-CSSTransition-interface}
interface CSSTransition : Animation {
  readonly attribute DOMString transitionProperty;
: transitionProperty :: The expanded transition property name of this transition.
This interface needs a constructor. Perhaps something like the following,
[Constructor (Animatable? target,
              DOMString transitionProperty,
              any transitionValue,
              optional (unrestricted double or KeyframeEffectOptions) options),
 Constructor (Animatable? target,
              DOMString transitionProperty,
              any transitionValue,
              (unrestricted double or KeyframeEffectOptions) options,
              AnimationTimeline? timeline)]
partial interface CSSTransition { };
Using any as the type for transitionValue would allow the following usage:
  var transition = new CSSTransition(elem, 'opacity', 1, 2000);
The above example, however, is not equivalent to triggering a transition. It has the following differences: * It does not update the specified style. * It would not cancel any existing transition on the given property unless we add special wording to that effect. * It would exhibit different composite order to a regular transition (this should be easily fixed, however). * It has been suggested that script-generated animations should not apply to the transition level of the cascade. It is unclear how much we should extend the {{CSSTransition}} constructor to overcome the above limitations so that it can be used to generate transitions programmatically, or whether we should introduce a separate helper method such as has been suggested elsewhere.
## Requirements on pending style changes ## {#requirements-on-pending-style-changes} Various operations may affect the computed values of properties on elements. User agents may, as an optimization, defer recomputing these values until it becomes necessary. However, all operations included in programming interface defined in this specification, as well as those operations defined in Web Animations [[!WEB-ANIMATIONS]] that may return objects defined by this specification, must produce a result consistent with having fully processed any such pending changes to computed values.
As an example, in the following code fragment, when the specified value of elem's 'opacity' property is updated, a user agent may defer recalculating the computed value of the 'animation' property. The first time this occurs, calling {{Window/getComputedStyle(elt)}} and subsequently accessing the opacity property of the result will cause the user agent to recompute the value of opacity. After the 'opacity' property is updated a second time, the {{Animatable/getAnimations()}} method is called on elem. This method is specified by Web Animations and can return {{CSSTransition}} objects as defined in this specification. Hence, as result of the requirements in this section, the user agent must apply any pending style changes thus generating a new {{CSSTransition}} for the 'opacity' property before returning its result.
elem.style.transition = 'opacity 100s';
elem.style.opacity = '0';
window.getComputedStyle(elem).opacity; // 0
elem.style.opacity = '1';
elem.getAnimations()[0].transitionProperty // 'opacity'

Issues commonly raised as issues with previous levels

These issues were commonly reported issues with the previous level of the specification.

More powerful timing function syntax is a common request from developers. See, for example: 2013 message or 2015 thread.

Developers frequently have to trigger style flushes in order to force transitions to start. It would be good to have an API that would avoid this requirement. See, for example, 2011 proposal.

Issues deferred from previous levels of the spec

These issues were in previous levels of the specification, but may not turn out to be important in this level either.

We may ultimately want to support a keypath syntax for the 'transition-property' property. A keypath syntax would enable different transitions to be specified for components of a property. For example the blur of a shadow could have a different transition than the color of a shadow.