Overview.bs

<style type="text/css">
  table.event-state-transitions {
    width: 100%;
    border-spacing: 0px;
    border-collapse: collapse;
  }
  table.event-state-transitions th:first-child {
    width: 30%;
  }
  table.event-state-transitions th {
    text-align: center;
  }
  table.event-state-transitions td {
    padding: 0.2em 1em;
    border: 1px solid black;
  }
</style>

<pre class='metadata'>
Title: CSS Transitions Level 2
Status: ED
Work Status: Exploring
Shortname: css-transitions-2
Level: 2
Group: csswg
ED: https://drafts.csswg.org/css-transitions-2/
Editor: L. David Baron, Mozilla https://www.mozilla.org/, https://dbaron.org/, w3cid 15393
Issue Tracking: Bugzilla bugs for all levels https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&amp;product=CSS&amp;component=Transitions&amp;resolution=---
Abstract: CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration.
Ignored Terms: translate, rotate, scale
</pre>
<pre class="anchors">
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: active duration
    text: active time
    text: animation
    text: animation class
    text: animation playback rate
    text: current iteration
    text: current time
    text: fill mode
    text: global animation list
    text: idle play state
    text: iteration duration
    text: iteration start
    text: pending play state
    text: sampling
    text: start delay
    text: target effect
    text: target effect end
    text: unresolved
</pre>
<pre class=link-defaults>
spec:css-transitions-1; type:value; text:all
</pre>

<h2 id="delta">Delta specification</h2>

	<p>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.</p>

# Starting of transitions # {#starting}

Associated with each top-level browsing context is a <dfn>current transition
generation</dfn> that is incremented on each <a>style change event</a>.

Each time a new transition is generated, the current value of the (already
incremented) <a>current transition generation</a> is stored as the
transition's <dfn>transition generation</dfn>.

## 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 <dfn>expanded transition property
name</dfn> 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 <dfn>owning element</dfn> 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 <a>owning element</a>.

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 <a>owning
element</a> (that is, it has no <a>owning element</a> 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}

<a spec='web-animations'>Animations</a> generated from the markup and
interfaces (e.g. the {{CSSTransition}} constructor) defined in this
specification have an <a>animation class</a> of &lsquo;CSS Transition&rsquo;.

CSS Transitions have an <em>earlier</em> composite order that CSS Animations
and animations without a specific <a>animation class</a>.

Within the set of CSS Transitions, two animations <var>A</var> and <var>B</var>
are sorted in composite order (first to last) as follows:

1.  If neither <var>A</var> nor <var>B</var> has an <a>owning element</a>,
    sort based on their relative position in the <a>global animation list</a>.

1.  Otherwise, if  only one of <var>A</var> or <var>B</var> has an <a>owning
    element</a>, let the animation <em>with</em> an <a>owning element</a> sort
    first.

1.  Otherwise, if the <a>owning element</a> of <var>A</var> and <var>B</var>
    differs, sort <var>A</var> and <var>B</var> by <a>tree order</a>
    of their corresponding <a>owning elements</a>.
    With regard to pseudo-elements, the sort order is as follows:

    *  element
    *  ::before
    *  ::after
    *  element children

1.  Otherwise, if <var>A</var> and <var>B</var> have different <a>transition
    generation</a> values, sort by their corresponding
    <a>transition generation</a> in ascending order.

1.  Otherwise, sort <var>A</var> and <var>B</var> in ascending order by the
    Unicode codepoints that make up the <a>expanded transition property
    name</a> of each transition (i.e. without attempting case conversion and
    such that &lsquo;-moz-column-width&rsquo; sorts before
    &lsquo;column-width&rsquo;).

Transitions generated using the markup defined in this specification are
<em>not</em> added to the <a>global animation list</a> when they are created.
Instead, these animations are appended to the <a>global animation list</a> at
the first moment when they transition out of the <a>idle play state</a> after
being disassociated from their <a>owning element</a>.
Transitions that have been disassociated from their <a>owning element</a>
but are still <a lt="idle play state">idle</a> do not have a defined
composite order.

Note, this behavior relies on the fact that disassociating a transition
from its <a>owning element</a> always causes it to enter (or remain) in the
<a>idle play state</a>.

Transitions created using the {{CSSTransition}} constructor are appended
to the <a>global animation list</a> at the moment they are constructed.

# Transition Events # {#transition-events}

## Event dispatch ## {#event-dispatch}

Note, this is a more general description of event dispatch than that of CSS
Transitions Level 1 [[CSS3-TRANSITIONS]] since it must account for the
possibility of animations being seeked or reversed using the Web Animations API
[[WEB-ANIMATIONS]]. Furthermore, it is possible using the Web Animations API
to substitute the transition effect with an entirely different effect with
properties not normally used with transitions (e.g. an effect that repeats
multiple times) and hence this section provides a generic definition that
accounts for the full complexity of the Web Animations model.

To avoid firing redundant events, the set of events to dispatch is based
on comparing the <a lt="transition phase">phase</a> of the transition in the
previous <a lt="sampling">sample</a> (animation frame) to its current state.

The <dfn>transition phase</dfn> of a transition is initially &lsquo;idle&rsquo;
and is updated on each sample according to the first matching condition from
below:

<dl class=switch>
   <dt>If the transition has no <a>target effect</a>,
   <dd>
     The transition phase is set according to the first matching condition
     from below:
     <dl class=switch>
       <dt>If the transition has an <a>unresolved</a> <a>current time</a>,
       <dd>The transition phase is &lsquo;idle&rsquo;.
       <dt>If the transition has a <a>current time</a> &lt; 0,
       <dd>The transition phase is &lsquo;before&rsquo;.
       <dt>Otherwise,
       <dd>The transition phase is &lsquo;after&rsquo;.
     </dl>
   <dt>If the transition is <a lt="pending play state">pending</a> and its
       phase was previously &lsquo;idle&rsquo; or &lsquo;pending&rsquo;,
   <dd>The transition phase is &lsquo;pending&rsquo;.
   <dt>Otherwise,
   <dd>The transition phase is the
       [[web-animations#animation-effect-phases-and-states|phase]] of its
       <a>target effect</a>.
</dl>

For calculating the {{TransitionEvent/elapsedTime}} of each event, the following
definitions are used:

*   <dfn>interval start</dfn> =
    <code>max(min(-<a>start delay</a>, <a>active duration</a>), 0)</code>
*   <dfn>interval end</dfn> =
    <code>max(min(<a>target effect end</a> - <a>start delay</a>,
                  <a>active duration</a>), 0)</code>

In the above formulae, references to the <a>start delay</a>, <a>active
duration</a>, <a>current iteration</a>, <a>iteration start</a>, and
<a>iteration duration</a> of a transition should be understood to refer
to the corresponding properties of the transition's <a>target effect</a>.

Each time an animation is <a lt="sampling">sampled</a>, the events to
dispatch are determined by comparing the <a>transition phase</a> before and
after the sample as follows:

<table class="event-state-transitions">
  <thead>
    <tr>
      <th>Change</th>
      <th>Events dispatched</th>
      <th><dfn>Elapsed time</dfn> (ms)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>idle &rarr; pending or before</td>
      <td>{{transitionrun}}</td>
      <td><a>interval start</a></td>
    </tr>
    <tr>
      <td rowspan="2">idle &rarr; active <a
          href="#multiple-events-note">&#x66d;</a></td>
      <td>{{transitionrun}}</td>
      <td rowspan="2"><a>interval start</a></td>
    </tr>
    <tr>
      <td>{{transitionstart}}</td>
    </tr>
    <tr>
      <td rowspan="3">idle &rarr; after <a
          href="#multiple-events-note">&#x66d;</a></td>
      <td>{{transitionrun}}</td>
      <td rowspan="2"><a>interval start</a></td>
    </tr>
    <tr>
      <td>{{transitionstart}}</td>
    </tr>
    <tr>
      <td>{{transitionend}}</td>
      <td><a>interval end</a></td>
    </tr>
    <tr>
      <td>pending or before &rarr; active</td>
      <td>{{transitionstart}}</td>
      <td><a>interval start</a></td>
    </tr>
    <tr>
      <td rowspan="2">pending or before &rarr; after <a
                      href="#multiple-events-note">&#x66d;</a></td>
      <td>{{transitionstart}}</td>
      <td><a>interval start</a></td>
    </tr>
    <tr>
      <td>{{transitionend}}</td>
      <td><a>interval end</a></td>
    </tr>
    <tr>
      <td>active &rarr; after</td>
      <td>{{transitionend}}</td>
      <td><a>interval end</a></td>
    </tr>
    <tr>
      <td>active &rarr; before</td>
      <td>{{transitionend}}</td>
      <td><a>interval start</a></td>
    </tr>
    <tr>
      <td>after &rarr; active</td>
      <td>{{transitionstart}}</td>
      <td><a>interval end</a></td>
    </tr>
    <tr>
      <td rowspan="2">after &rarr; before <a
                      href="#multiple-events-note">&#x66d;</a></td>
      <td>{{transitionstart}}</td>
      <td><a>interval end</a></td>
    </tr>
    <tr>
      <td>{{transitionend}}</td>
      <td><a>interval start</a></td>
    </tr>
    <tr>
      <td><em>not</em> idle and <em>not</em> after &rarr; idle</td>
      <td>{{transitioncancel}}</td>
      <td>The <a>active time</a> of the animation at the moment it was cancelled
          calculated using a <a>fill mode</a> of both.</td>
    </tr>
  </tbody>
</table>

<p id="multiple-events-note">&#x66d; Where multiple events are listed for
a state change, all events are dispatched in the order listed and in immediate
succession.</p>

Since the <a>elapsed time</a> defined in the table and procedure above is
expressed in milliseconds, it must be divided by 1,000 to produce a value in
seconds before being assigned to the {{TransitionEvent/elapsedTime}} member of
the {{TransitionEvent}}.

<div class="note">

  The above state transition chart ensures that, with the exception of
  transitions that are paused or have an infinite running time, the following
  invariants hold:

  * For every {{transitionrun}} event there will be a exactly one
    {{transitionend}} <em>or</em> {{transitioncancel}} and never both.
  * For every {{transitionstart}} event there will be a exactly one
    {{transitionend}} <em>or</em> {{transitioncancel}} and never both.
  * Every {{transitionend}} event is preceded by a corresponding
    {{transitionstart}} event.

  The typical sequences of events, then, are as follows:

  * Regular playback: {{transitionrun}}, {{transitionstart}}, {{transitionend}}.
  * Interrupted playback: {{transitionrun}}, {{transitionstart}},
    {{transitioncancel}}.
  * Interrupted playback during delay or pending phase: {{transitionrun}},
    {{transitioncancel}}.
  * Reversed playback after completion: {{transitionrun}}, {{transitionstart}},
    {{transitionend}}, {{transitionstart}}, {{transitionend}}.

</div>

# DOM Interfaces # {#interface-dom}

## The CSSTransition interface ## {#the-CSSTransition-interface}

<pre class="idl">
[Exposed=Window]
interface CSSTransition : Animation {
  readonly attribute CSSOMString transitionProperty;
};
</pre>

:   <dfn attribute for=CSSTransition>transitionProperty</dfn>
::  The <a>expanded transition property name</a> of this transition.

<div class="issue">

This interface needs a constructor. Perhaps something like the following,

<pre class="idl">
[Constructor (Animatable? target,
              CSSOMString transitionProperty,
              any transitionValue,
              optional (unrestricted double or KeyframeEffectOptions) options),
 Constructor (Animatable? target,
              CSSOMString transitionProperty,
              any transitionValue,
              (unrestricted double or KeyframeEffectOptions) options,
              AnimationTimeline? timeline)]
partial interface CSSTransition { };
</pre>

Using <code>any</code> as the type for <code>transitionValue</code> would allow
the following usage:

<pre class="example lang-javascript">
  var transition = new CSSTransition(elem, 'opacity', 1, 2000);
  transition.play();
</pre>

The above example, however, is <em>not</em> 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 <a
    href="https://github.com/w3c/web-animations/issues/62#issuecomment-117357703">script-generated
    animations should not apply to the transition level of the cascade</a>.

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 <a
href="https://lists.w3.org/Archives/Public/www-style/2011Mar/0729.html">suggested
elsewhere</a>.

</div>

## Requirements on pending style changes ## {#requirements-on-pending-style-changes}

Various operations may affect the <a lt="computed value">computed values</a> 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.

<div class="note">
As an example, in the following code fragment, when the specified value of
<code>elem</code>'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 <code>opacity</code> 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 <code>elem</code>.
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.

<div><pre class="example lang-javascript">
elem.style.transition = 'opacity 100s';
elem.style.opacity = '0';
window.getComputedStyle(elem).opacity; // 0
elem.style.opacity = '1';
elem.getAnimations()[0].transitionProperty // 'opacity'
</pre></div>

</div>

<h2 id="issues-common">Issues commonly raised as issues with previous levels</h2>

	<p>
		These issues were commonly reported issues
		with the previous level of the specification.
	</p>

	<div class="issue">
		<p>
			More powerful timing function syntax
			is a common request from developers.
			See, for example:
			<a href="https://lists.w3.org/Archives/Public/www-style/2013Jun/0376.html">2013 message</a>
			or
			<a href="https://lists.w3.org/Archives/Public/public-fx/2015JulSep/thread.html#msg34">2015 thread</a>.
		</p>
	</div>

	<div class="issue">
		<p>
			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,
			<a href="https://lists.w3.org/Archives/Public/www-style/2011Mar/0729.html">2011 proposal</a>.
		</p>
	</div>

<h2 id="issues-spec">Issues deferred from previous levels of the spec</h2>

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

	<div class="issue">
		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.
	</div>