CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration.
CSS is a language for describing the rendering of structured documents
(such as HTML and XML)
on screen, on paper, in speech, etc.
Status of this document
This is a public copy of the editors’ draft.
It is provided for discussion only and may change at any moment.
Its publication here does not imply endorsement of its contents by W3C.
Don’t cite this document other than as work in progress.
The (archived) public mailing list www-style@w3.org (see instructions)
is preferred for discussion of this specification.
When sending e-mail,
please put the text “css-transitions-2” in the subject,
preferably like this:
“[css-transitions-2] …summary of comment…”
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.
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).
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).
2.3. Animation composite order
Animations generated from the markup and
interfaces (e.g. the CSSTransition constructor) defined in this
specification have an animation class of ‘CSS Transition’.
CSS Transitions have an earlier composite order that CSS Animations
and animations without a specific animation class.
Within the set of CSS Transitions, two animations A and B are sorted in composite order (first to last) as follows:
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:
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.
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.
4.2. 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 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 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.
5. 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.
6. 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.
Conformance
Document conventions
Conformance requirements are expressed with a combination of
descriptive assertions and RFC 2119 terminology. The key words “MUST”,
“MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this
document are to be interpreted as described in RFC 2119.
However, for readability, these words do not appear in all uppercase
letters in this specification.
All of the text of this specification is normative except sections
explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example",
like this:
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from the
normative text with class="note", like this:
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention and are
set apart from other normative text with <strong class="advisement">, like
this: UAs MUST provide an accessible alternative.
Conformance classes
Conformance to this specification
is defined for three conformance classes:
A style sheet is conformant to this specification
if all of its statements that use syntax defined in this module are valid
according to the generic CSS grammar and the individual grammars of each
feature defined in this module.
A renderer is conformant to this specification
if, in addition to interpreting the style sheet as defined by the
appropriate specifications, it supports all the features defined
by this specification by parsing them correctly
and rendering the document accordingly. However, the inability of a
UA to correctly render a document due to limitations of the device
does not make the UA non-conformant. (For example, a UA is not
required to render color on a monochrome monitor.)
An authoring tool is conformant to this specification
if it writes style sheets that are syntactically correct according to the
generic CSS grammar and the individual grammars of each feature in
this module, and meet all other conformance requirements of style sheets
as described in this module.
Requirements for Responsible Implementation of CSS
The following sections define several conformance requirements
for implementing CSS responsibly,
in a way that promotes interoperability in the present and future.
Partial Implementations
So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid
(and ignore as appropriate)
any at-rules, properties, property values, keywords, and other syntactic constructs
for which they have no usable level of support.
In particular, user agents must not selectively ignore
unsupported property values and honor supported values in a single multi-value property declaration:
if any value is considered invalid (as unsupported values must be),
CSS requires that the entire declaration be ignored.
Implementations of Unstable and Proprietary Features
Once a specification reaches the Candidate Recommendation stage,
implementers should release an unprefixed implementation
of any CR-level feature they can demonstrate
to be correctly implemented according to spec,
and should avoid exposing a prefixed variant of that feature.
To establish and maintain the interoperability of CSS across
implementations, the CSS Working Group requests that non-experimental
CSS renderers submit an implementation report (and, if necessary, the
testcases used for that implementation report) to the W3C before
releasing an unprefixed implementation of any CSS features. Testcases
submitted to W3C are subject to review and correction by the CSS
Working Group.
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). ↵
This interface needs a constructor. Perhaps something like the following,
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.
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.
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. ↵