Overview.bs

<h1>CSS Transitions Level 2</h1>

<pre class='metadata'>
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, dbaron@dbaron.org
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: animation
    text: animation class
    text: global animation list
    text: idle play state
    text: start delay
    text: target effect
urlPrefix: https://drafts.csswg.org/css-animations-2/; type: dfn; spec: css-animations-2
    text: interval end
</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}

## Types of <code>TransitionEvent</code> ## {#transition-event-types}

	<p>The <em>additional</em> types of transition events that can occur are:</p>

	<dl dfn-type=event dfn-for=transitionevent>
		<dt><dfn>transitionrun</dfn>
		<dd>
			The <a idl>transitionrun</a> event occurs when a transition is created (i.e., when it is added to the set of <a>running transitions</a>).
			The {{AnimationEvent/elapsedTime}} in this case is equal to the value
			defined for the <a idl>transitionstart</a> event.

      Issue: Is there some more useful value we could provide here for the
      <code>elapsedTime</code>?

			<ul>
				<li>Bubbles: Yes</li>
				<li>Cancelable: No</li>
				<li>Context Info: propertyName, elapsedTime, pseudoElement</li>
			</ul>
		<dt><dfn>transitionstart</dfn>
		<dd>
			The <a idl>transitionstart</a> event occurs when a transition's delay
			phase ends.
			The {{AnimationEvent/elapsedTime}} in this case is the result of
			calculating
      <code>max(min(-<a>start delay</a>, <a>active duration</a>), 0)
      / 1000</code>
      where the <a>start delay</a> and <a>active duration</a> values refer
      to the values defined for the transition's <a>target effect</a>.

      Note: This calculation is roughly equivalent to saying,
      &ldquo;The <code>elapsedTime</code> is zero unless there is
      a negative 'transition-delay', in which cse the <code>elapsedTime</code>
      is the absolute value of the 'transition-delay'.&rdquo;
      However, it produces more useful results in some edge cases such as
      when the there is a negative delay greater in magnitude than the
      total duration of the animation.

			<ul>
				<li>Bubbles: Yes</li>
				<li>Cancelable: No</li>
				<li>Context Info: propertyName, elapsedTime, pseudoElement</li>
			</ul>
		<dt><dfn>transitioncancel</dfn>
		<dd>
			The <a idl>transitioncancel</a> event occurs when a transition is <a lt="cancel">cancelled</a>.
			The {{AnimationEvent/elapsedTime}} in this case is zero.

      Issue: Is there some more useful value we could provide here for the
      <code>elapsedTime</code>?
      (We could, for example, return the current time at the moment the
      transition was cancelled so that the author can tell if the transition
      had just started or was close to finishing and perhaps behave differently
      in each case.
      Doing that, however, would require implementations to store
      additional state for each transition which would be unfortunate if
      this is not a common use case.)

			<ul>
				<li>Bubbles: Yes</li>
				<li>Cancelable: No</li>
				<li>Context Info: propertyName, elapsedTime, pseudoElement</li>
			</ul>
	</dl>

<div class="issue">

We should define the dispatch of events more generally in light of
possible modifications to a transition's playback using the Web Animations API
like we do for CSS Animations (see the section on
[[css-animations-2#event-dispatch|event dispatch]]).

As part of this, we should clarify the calculation of the
{{AnimationEvent/elapsedTime}} member for <a idl>transitionend</a> events to
use the same <a>interval end</a> value defined for CSS Animations.

</div>

# DOM Interfaces # {#interface-dom}

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

<pre class="idl">
interface CSSTransition : Animation {
  readonly attribute DOMString 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,
              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 { };
</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>