csswg-drafts/css-transitions-2/Overview.bs at 51d614677ed9adb7dceff2f9f88364a797747729 · w3c/csswg-drafts · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
<h1>CSS Transitions Level 2</h1>

<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'>
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">
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>