CSS View Transitions Module Level 1

1. Introduction

This section is non-normative.

This specification introduces a DOM API and associated CSS features that allow developers to create animated visual transitions, called view transitions between different states of a document.

1.1. Separating Visual Transitions from DOM Updates

Traditionally, creating a visual transition between two document states required a period where both states were present in the DOM at the same time. In fact, it usually involved creating a specific DOM structure that could represent both states. For example, if one element was “moving” between containers, that element often needed to exist outside of either container for the period of the transition, to avoid clipping from either container or their ancestor elements.

This extra in-between state often resulted in UX and accessibility issues, as the structure of the DOM was compromised for a purely-visual effect.

View Transitions avoid this troublesome in-between state by allowing the DOM to switch between states instantaneously, then performing a customizable visual transition between the two states in another layer, using a static visual capture of the old state, and a live capture of the new state. These captures are represented as a tree of pseudo-elements (detailed in § 3.2 View Transition Pseudo-elements), where the old visual state co-exists with the new state, allowing effects such as cross-fading while animating from the old to new size and position.

1.2. View Transition Customization

By default, document.startViewTransition() creates a view transition consisting of a page-wide cross-fade between the two DOM states. Developers can also choose which elements are captured independently using the view-transition-name CSS property, allowing these to be animated independently of the rest of the page. Since the transitional state (where both old and new visual captures exist) is represented as pseudo-elements, developers can customize each transition using familiar features such as CSS Animations and Web Animations.

1.3. View Transition Lifecycle

A successful view transition goes through the following phases:

1. Developer calls document.startViewTransition(updateCallback), which returns a ViewTransition, viewTransition.

2. Current state captured as the “old” state.

3. Rendering paused.

4. Developer’s updateCallback function, if provided, is called, which updates the document state.

5. viewTransition.updateCallbackDone fulfills.

6. Current state captured as the “new” state.

7. Transition pseudo-elements created. See § 3.2 View Transition Pseudo-elements for an overview of this structure.

8. Rendering unpaused, revealing the transition pseudo-elements.

9. viewTransition.ready fulfills.

10. Pseudo-elements animate until finished.

11. Transition pseudo-elements removed.

12. viewTransition.finished fulfills.

1.4. Transitions as an enhancement

A key part of the View Transition API design is that an animated transition is a visual enhancement to an underlying document state change. That means a failure to create a visual transition, which can happen due to misconfiguration or device constraints, will not prevent the developer’s ViewTransitionUpdateCallback being called, even if it’s known in advance that the transition animations cannot happen.

For example, if the developer calls skipTransition() at the start of the view transition lifecycle, the steps relating to the animated transition, such as creating the view transition tree, will not happen. However, the ViewTransitionUpdateCallback will still be called. It’s only the visual transition that’s skipped, not the underlying state change.

Note: If the DOM change should also be skipped, then that needs to be handled by another feature. navigateEvent.signal is an example of a feature developers could use to handle this.

Although the View Transition API allows DOM changes to be asynchronous via the ViewTransitionUpdateCallback, the API is not responsible for queuing or otherwise scheduling DOM changes beyond any scheduling needed for the transition itself. Some asynchronous DOM changes can happen concurrently (e.g if they’re happening within independent components), whereas others need to queue, or abort an earlier change. This is best left to a feature or framework that has a more holistic view of the application.

1.5. Rendering Model

View Transition works by replicating an element’s rendered state using UA generated pseudo-elements. Aspects of the element’s rendering which apply to the element itself or its descendants, for example visual effects like filter or opacity and clipping from overflow or clip-path, are applied when generating its image in Capture the image.

However, properties like mix-blend-mode which define how the element draws when it is embedded can’t be applied to its image. Such properties are applied to the element’s corresponding ::view-transition-group() pseudo-element, which is meant to generate a box equivalent to the element.

If the ::view-transition-group() has a corresponding element in the "new" states, the browser keeps the properties copied over to the ::view-transition-group() in sync with the DOM element in the "new" state. If the ::view-transition-group() has a corresponding both in the "old" and "new" state, and the property being copied is interpolatable, the browser also sets up a default animation to animate the property smoothly.

1.6. Examples

function spaNavigate(data) {
  updateTheDOMSomehow(data);
}

function spaNavigate(data) {
  // Fallback for browsers that don't support this API:
  if (!document.startViewTransition) {
    updateTheDOMSomehow(data);
    return;
  }

  // With a transition:
  document.startViewTransition(() => updateTheDOMSomehow(data));
}

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 5s;
}

@keyframes fade-in {
  from { opacity: 0; }
}

@keyframes fade-out {
  to { opacity: 0; }
}

@keyframes slide-from-right {
  from { transform: translateX(30px); }
}

@keyframes slide-to-left {
  to { transform: translateX(-30px); }
}

::view-transition-old(root) {
  animation: 90ms cubic-bezier(0.4, 0, 1, 1) both fade-out,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-to-left;
}

::view-transition-new(root) {
  animation: 210ms cubic-bezier(0, 0, 0.2, 1) 90ms both fade-in,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-from-right;
}

.main-header {
  view-transition-name: main-header;
}

.main-header-text {
  view-transition-name: main-header-text;
  /* Give the element a consistent size, assuming identical text: */
  width: fit-content;
}

.sidebar {
  view-transition-name: sidebar;
}

@keyframes slide-to-right {
  to { transform: translateX(30px); }
}

/* Entry transition */
::view-transition-new(sidebar):only-child {
  animation: 300ms cubic-bezier(0, 0, 0.2, 1) both fade-in,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-from-right;
}

/* Exit transition */
::view-transition-old(sidebar):only-child {
  animation: 150ms cubic-bezier(0.4, 0, 1, 1) both fade-out,
    300ms cubic-bezier(0.4, 0, 0.2, 1) both slide-to-right;
}

::view-transition-image-pair(root) {
  isolation: auto;
}

::view-transition-old(root),
::view-transition-new(root) {
  animation: none;
  mix-blend-mode: normal;
}

// Store the last click event
let lastClick;
addEventListener('click', event => (lastClick = event));

function spaNavigate(data) {
  // Fallback for browsers that don't support this API:
  if (!document.startViewTransition) {
    updateTheDOMSomehow(data);
    return;
  }

  // Get the click position, or fallback to the middle of the screen
  const x = lastClick?.clientX ?? innerWidth / 2;
  const y = lastClick?.clientY ?? innerHeight / 2;
  // Get the distance to the furthest corner
  const endRadius = Math.hypot(
    Math.max(x, innerWidth - x),
    Math.max(y, innerHeight - y)
  );

  // Create a transition:
  const transition = document.startViewTransition(() => {
    updateTheDOMSomehow(data);
  });

  // Wait for the pseudo-elements to be created:
  transition.ready.then(() => {
    // Animate the root's new view
    document.documentElement.animate(
      {
        clipPath: [
          \`circle(0 at ${x}px ${y}px)\`,
          \`circle(${endRadius}px at ${x}px ${y}px)\`,
        ],
      },
      {
        duration: 500,
        easing: 'ease-in',
        // Specify which pseudo-element to animate
        pseudoElement: '::view-transition-new(root)',
      }
    );
  });
}

2. CSS properties

2.1. Tagging Individually Transitioning Subtrees: the view-transition-name property

Note: though view-transition-name is discretely animatable, animating it doesn’t affect the running view transition. Rather, it’s a way to set its value in a way that can change over time or based on a timeline. An example for using this would be to change the view-transition-name based on scroll-driven animations.

The view-transition-name property “tags” an element for capture in a view transition, tracking it independently in the view transition tree under the specified view transition name. An element so captured is animated independently of the rest of the page.

none

The element will not participate independently in a view transition.

<custom-ident>

The element participates independently in a view transition—​as either an old or new element—​with the specified view transition name.

Each view transition name is a tree-scoped name.

Note: Since currently only document-scoped view transitions are supported, only view transition names that are associated with the document are respected.

The values none and auto are excluded from <custom-ident> here.

Note: If this name is not unique (i.e. if two elements simultaneously specify the same view transition name) then the view transition will abort.

Note: For the purposes of this API, if one element has view transition name foo in the old state, and another element has view transition name foo in the new state, they are treated as representing different visual state of the same element, and will be paired in the view transition tree. This may be confusing, since the elements themselves are not necessarily referring to the same object, but it is a useful model to consider them to be visual states of the same conceptual page entity.

If the element’s principal box is fragmented, skipped, or not rendered, this property has no effect. See § 7 Algorithms for exact details.

2.1.1. Rendering Consolidation

Elements captured in a view transition during a view transition or whose view-transition-name computed value is not none (at any time):

• Form a stacking context.

• Are flattened in 3D transforms.

• Form a backdrop root.

3. Pseudo-elements

3.1. Pseudo-element Trees

Note: This is a general definition for trees of pseudo-elements. If other features need this behavior, these definitions will be moved to [css-pseudo-4].

A pseudo-element root is a type of tree-abiding pseudo-element that is the root in a tree of tree-abiding pseudo-elements, known as the pseudo-element tree.

The pseudo-element tree defines the document order of its descendant tree-abiding pseudo-elements.

When a pseudo-element participates in a pseudo-element tree, its originating pseudo-element is its parent.

If a descendant pseudo of a pseudo-element root has no other siblings, then :only-child matches that pseudo.

Note: This means that ::view-transition-new(ident):only-child will only select ::view-transition-new(ident) if the parent ::view-transition-image-pair(ident) contains a single child. As in, there is no sibling ::view-transition-old(ident).

3.2. View Transition Pseudo-elements

The visualization of a view transition is represented as a pseudo-element tree called the view transition tree composed of the view transition pseudo-elements defined below. This tree is built during the setup transition pseudo-elements step, and is rooted under a ::view-transition pseudo-element originating from the root element. All of the view transition pseudo-elements are selected from their ultimate originating element, the document element.

The view transition tree is not exposed to the accessibility tree.

::view-transition
├─ ::view-transition-group(name)
│  └─ ::view-transition-image-pair(name)
│     ├─ ::view-transition-old(name)
│     └─ ::view-transition-new(name)
└─ …other groups…

3.2.1. Named View Transition Pseudo-elements

Several of the view transition pseudo-elements are named view transition pseudo-elements, which are functional tree-abiding view transition pseudo-elements associated with a view transition name. These pseudo-elements take a <pt-name-selector> as their argument, and their syntax follows the pattern:

::view-transition-pseudo(<pt-name-selector>)

where <pt-name-selector> selects a view transition name, and has the following syntax definition:

<pt-name-selector> = '*' | <custom-ident>

A named view transition pseudo-element selector only matches a corresponding pseudo-element if its <pt-name-selector> matches that pseudo-element’s view transition name, i.e. if it is either * or a matching <custom-ident>.

Note: The view transition name of a view transition pseudo-element is set to the view-transition-name that triggered its creation.

The specificity of a named view transition pseudo-element selector with a <custom-ident> argument is equivalent to a type selector. The specificity of a named view transition pseudo-element selector with a * argument is zero.

3.2.2. View Transition Tree Root: the ::view-transition pseudo-element

The ::view-transition pseudo-element is a tree-abiding pseudo-element that is also a pseudo-element root. Its originating element is the document’s document element, and its containing block is the snapshot containing block.

Note: This element serves as the parent of all ::view-transition-group() pseudo-elements.

3.2.3. View Transition Named Subtree Root: the ::view-transition-group() pseudo-element

The ::view-transition-group() pseudo-element is a named view transition pseudo-element that represents a matching named view transition capture. A ::view-transition-group() pseudo-element is generated for each view transition name as a child of the ::view-transition pseudo-element, and contains a corresponding ::view-transition-image-pair().

3.2.4. View Transition Image Pair Isolation: the ::view-transition-image-pair() pseudo-element

The ::view-transition-image-pair() pseudo-element is a named view transition pseudo-element that represents a pair of corresponding old/new view transition captures. This pseudo-element is a child of the corresponding ::view-transition-group() pseudo-element and contains a corresponding ::view-transition-old() pseudo-element and/or a corresponding ::view-transition-new() pseudo-element (in that order).

3.2.5. View Transition Old State Image: the ::view-transition-old() pseudo-element

The ::view-transition-old() pseudo-element is an empty named view transition pseudo-element that represents a visual snapshot of the “old” state as a replaced element; it is omitted if there’s no “old” state to represent. Each ::view-transition-old() pseudo-element is a child of the corresponding ::view-transition-image-pair() pseudo-element.

Note: The content and natural dimensions of the image are captured in capture the image, and set in setup transition pseudo-elements.

Note: Additional styles in the dynamic view transition style sheet added to animate these pseudo-elements are detailed in setup transition pseudo-elements and update pseudo-element styles.

3.2.6. View Transition New State Image: the ::view-transition-new() pseudo-element

The ::view-transition-new() pseudo-element (like the analogous ::view-transition-old() pseudo-element) is an empty named view transition pseudo-element that represents a visual snapshot of the “new” state as a replaced element; it is omitted if there’s no “new” state to represent. Each ::view-transition-new() pseudo-element is a child of the corresponding ::view-transition-image-pair() pseudo-element.

Note: The content and natural dimensions of the image are captured in capture the image, then set and updated in setup transition pseudo-elements and update pseudo-element styles.

4. View Transition Layout

The view transition pseudo-elements are styled, laid out, and rendered like normal elements, except that they originate in the snapshot containing block rather than the initial containing block and are painted in the view transition layer above the rest of the document.

4.1. The Snapshot Containing Block

The snapshot containing block is a rectangle that covers all areas of the window that could potentially display page content (and is therefore consistent regardless of root scrollbars or interactive widgets). This makes it likely to be consistent for the document element's old image and new element.

Within a child navigable, the snapshot containing block is the union of the navigable’s viewport with any scrollbar gutters.

The snapshot containing block origin refers to the top-left corner of the snapshot containing block.

The snapshot containing block size refers to the width and height of the snapshot containing block as a tuple of two numbers.

The snapshot containing block is considered to be an absolute positioning containing block and a fixed positioning containing block for ::view-transition and its descendants.

4.2. View Transition Painting Order

This specification introduces a new stacking layer, the view transition layer, to the end of the painting order established in CSS2§E Elaborate Description of Stacking Contexts. [CSS2]

The ::view-transition pseudo-element generates a new stacking context, called the view transition layer, which paints after all other content of the document (including any content rendered in the top layer), after any filters and effects that are applied to such content. (It is not subject to such filters or effects, except insofar as they affect the rendered contents of the ::view-transition-old() and ::view-transition-new() pseudo-elements.)

Note: The intent of the feature is to be able to capture the contents of the page, which includes the top layer elements. In order to accomplish that, the view transition layer cannot be a part of the captured stacking contexts, since that results in a circular dependency. Therefore, the view transition layer is a sibling of all other content.

When a Document's active view transition's phase is "animating", the boxes generated by any element in that Document with captured in a view transition and its element contents, except transition root pseudo-element's inclusive descendants, are not painted (as if they had visibility: hidden) and do not respond to hit-testing (as if they had pointer-events: none).

Note: Elements participating in a transition need to skip painting in their DOM location because their image is painted in the corresponding ::view-transition-new() pseudo-element instead. Similarly, hit-testing is skipped because the element’s DOM location does not correspond to where its contents are rendered. However, there is no change in how these elements are accessed by assistive technologies or the accessibility tree.

5. User Agent Stylesheet

The global view transition user agent style sheet is a user-agent origin style sheet containing the following rules:

:root {
  view-transition-name: root;
}

:root::view-transition {
  position: fixed;
  inset: 0;
}

:root::view-transition-group(*) {
  position: absolute;
  top: 0;
  left: 0;

  animation-duration: 0.25s;
  animation-fill-mode: both;
}

:root::view-transition-image-pair(*) {
  position: absolute;
  inset: 0;

  animation-duration: inherit;
  animation-fill-mode: inherit;
  animation-delay: inherit;
}

:root::view-transition-old(*),
:root::view-transition-new(*) {
  position: absolute;
  inset-block-start: 0;
  inline-size: 100%;
  block-size: auto;

  animation-duration: inherit;
  animation-fill-mode: inherit;
  animation-delay: inherit;
}

/* Default cross-fade transition */
@keyframes -ua-view-transition-fade-out {
  to { opacity: 0; }
}
@keyframes -ua-view-transition-fade-in {
  from { opacity: 0; }
}

/* Keyframes for blending when there are 2 images */
@keyframes -ua-mix-blend-mode-plus-lighter {
  from { mix-blend-mode: plus-lighter }
  to { mix-blend-mode: plus-lighter }
}

Additional styles are dynamically added to the user-agent origin during a view transition through the dynamic view transition style sheet.

6. API

6.1. Additions to Document

partial interface Document {
  ViewTransition startViewTransition(optional ViewTransitionUpdateCallback updateCallback);
};

callback ViewTransitionUpdateCallback = Promise<any> ();

viewTransition = document.startViewTransition(updateCallback)

Starts a new view transition (canceling the document’s existing active view transition, if any).

updateCallback, if provided, is called asynchronously, once the current state of the document is captured. Then, when the promise returned by updateCallback fulfills, the new state of the document is captured and the transition is initiated.

Note that updateCallback, if provided, is always called, even if the transition cannot happen (e.g. due to duplicate view-transition-name values). The transition is an enhancement around the state change, so a failure to create a transition never prevents the state change. See § 1.4 Transitions as an enhancement for more details on this principle.

If the promise returned by updateCallback rejects, the transition is skipped.

6.1.1. startViewTransition() Method Steps

6.2. The ViewTransition interface

[Exposed=Window]
interface ViewTransition {
  readonly attribute Promise<undefined> updateCallbackDone;
  readonly attribute Promise<undefined> ready;
  readonly attribute Promise<undefined> finished;
  undefined skipTransition();
};

The ViewTransition interface represents and controls a single same-document view transition, i.e. a transition where the starting and ending document are the same, possibly with changes to the document’s DOM structure.

viewTransition.updateCallbackDone

A promise that fulfills when the promise returned by updateCallback fulfills, or rejects when it rejects.

Note: The View Transition API wraps a DOM change and creates a visual transition. However, sometimes you don’t care about the success/failure of the transition animation, you just want to know if and when the DOM change happens. updateCallbackDone is for that use-case.)

viewTransition.ready

A promise that fulfills once the pseudo-elements for the transition are created, and the animation is about to start.

It rejects if the transition cannot begin. This can be due to misconfiguration, such as duplicate 'view-transition-name’s, or if updateCallbackDone returns a rejected promise.

The point that ready fulfills is the ideal opportunity to animate the view transition pseudo-elements with the Web Animation API.

viewTransition.finished

A promise that fulfills once the end state is fully visible and interactive to the user.

It only rejects if updateCallback returns a rejected promise, as this indicates the end state wasn’t created.

Otherwise, if a transition fails to begin, or is skipped (by skipTransition()), the end state is still reached, so finished fulfills.

viewTransition.skipTransition()

Immediately finish the transition, or prevent it starting.

This never prevents updateCallback being called, as the DOM change is independent of the transition. See § 1.4 Transitions as an enhancement for more details on this principle.

If this is called before ready resolves, ready will reject.

If finished hasn’t resolved, it will fulfill or reject along with updateCallbackDone.

A ViewTransition has the following:

named elements

a map, whose keys are view transition names and whose values are captured elements. Initially a new map. Note: Since this is associated to the ViewTransition, it will be cleaned up when Clear view transition is called.

phase

One of the following ordered phases, initially "pending-capture":

1. "pending-capture".

2. "update-callback-called".

3. "animating".

4. "done".

Note: For the most part, a developer using this API does not need to worry about the different phases, since they progress automatically. It is, however, important to understand what steps happen in each of the phases: when the snapshots are captured, when pseudo-element DOM is created, etc. The description of the phases below tries to be as precise as possible, with an intent to provide an unambiguous set of steps for implementors to follow in order to produce a spec-compliant implementation.

update callback

a ViewTransitionUpdateCallback or null. Initially null.

ready promise

a Promise. Initially a new promise in this’s relevant Realm.

update callback done promise

a Promise. Initially a new promise in this’s relevant Realm.

Note: The ready promise and update callback done promise are immediately created, so rejections will cause unhandledrejections unless they’re handled, even if the getters such as updateCallbackDone are not accessed.

finished promise

a Promise. Initially a new promise in this’s relevant Realm, marked as handled.

Note: This is marked as handled to prevent duplicate unhandledrejections, as this promise only ever rejects along with the update callback done promise.

transition root pseudo-element

a ::view-transition. Initially a new ::view-transition.

initial snapshot containing block size

a tuple of two numbers (width and height), or null. Initially null.

Note: This is used to detect changes in the snapshot containing block size, which causes the transition to skip. Discussion of this behavior.

The finished getter steps are to return this’s finished promise.

The ready getter steps are to return this’s ready promise.

The updateCallbackDone getter steps are to return this’s update callback done promise.

6.2.1. skipTransition() Method Steps

7. Algorithms

7.1. Data Structures

7.1.1. Additions to Document

A Document additionally has:

active view transition

a ViewTransition or null. Initially null.

rendering suppression for view transitions

a boolean. Initially false.

While a Document’s rendering suppression for view transitions is true, all pointer hit testing must target its document element, ignoring all other elements.

Note: This does not affect pointers that are captured.

dynamic view transition style sheet

a style sheet. Initially a new style sheet in the user-agent origin, ordered after the global view transition user agent style sheet.

Note: This is used to hold dynamic styles relating to transitions.

show view transition tree

A boolean. Initially false.

When this is true, this's active view transition's transition root pseudo-element renders as a child of this's document element, with this's document element is its originating element.

Note: The position of the transition root pseudo-element within the document element does not matter, as the transition root pseudo-element's containing block is the snapshot containing block.

7.1.2. Additions to Elements

Elements have a captured in a view transition boolean, initially false.

Note: This spec uses CSS’s definition of element, which includes pseudo-elements.

7.1.3. Captured elements

A captured element is a struct with the following:

old image

an 2D bitmap or null. Initially null.

old width

old height

an unrestricted double, initially zero.

old transform

a <transform-function>, initially the identity transform function.

old writing-mode

Null or a writing-mode, initially null.

old direction

Null or a direction, initially null.

old text-orientation

Null or a text-orientation, initially null.

old mix-blend-mode

Null or a mix-blend-mode, initially null.

old backdrop-filter

Null or a backdrop-filter, initially null.

old color-scheme

Null or a color-scheme, initially null.

new element

an element or null. Initially null.

In addition, a captured element has the following style definitions:

group keyframes

A CSSKeyframesRule or null. Initially null.

group animation name rule

A CSSStyleRule or null. Initially null.

group styles rule

A CSSStyleRule or null. Initially null.

image pair isolation rule

A CSSStyleRule or null. Initially null.

image animation name rule

A CSSStyleRule or null. Initially null.

Note: These are used to update, and later remove styles from a document's dynamic view transition style sheet.

7.2. Perform pending transition operations

7.3. Setup view transition

7.3.1. Capture the old state

7.3.2. Capture the new state

7.3.3. Setup transition pseudo-elements

7.4. Call the update callback

7.5. Skip the view transition

7.6. View transition page-visibility change steps

7.7. Capture the image

7.7.1. Capture rendering characteristics

7.8. Handle transition frame

7.9. Update pseudo-element styles

7.10. Clear view transition

Privacy Considerations

This specification introduces no new privacy considerations.

Security Considerations

The images generated using capture the image algorithm could contain cross-origin data (if the Document is embedding cross-origin resources) or sensitive information like visited links. The implementations must ensure this data can not be accessed by the Document. This should be feasible since access to this data should already be prevented in the default rendering of the Document.

Appendix A. Changes

This appendix is informative.

Changes from 2023-05-30 Working Draft

• Use a keyframe to add plus-lighter blending during cross-fade. See issue 8924.

• Add mix-blend-mode to list of properties copied over to the ::view-transition-group. See issue 8962.

• Add text-orientation to list of properties copied over to the ::view-transition-group. See issue 8230.

• Refactor the old capture algorithm to properly set captured in a view transition before reading the value.

• Make the startViewTransition() parameter non-nullable. See issue 9460.

• Elements participating in a view transition are exposed to accessibility tree. See issue 9365.

• The view transition tree is not exposed to accessibility tree. See issue 9365.

• Animate back-drop filter similar to transform/size. See issue 9358.

• Copy color-scheme from DOM element to ::view-transition-group(). See issue 9276.

• Expose auto-skip view transition for a Document, to allow having outbound cross-document transitions preceed programmatic view transiitons. see issue 9512.

• Add a note about why view-transition-name should be animatable.

• view-transition-name: auto should be an invalid value. See issue 9639.

• Add note to explain paint order for entry animations. See issue 9672.

• Add note to explain how the named elements are cleaned up. See issue 9669.

• Refactor algorithm to clarify timing, especially of `updateCallbackDone. See issue 9762.

• Add animation-delay inherit to UA stylesheet rules for (::view-transition) -image-pair, -old, and -new. See issue 9817.

• Auto-skip animation when document is hidden. See issue 9543.

• Remove references to cross-document view-transitions, to keep the L1 spec clean. See Issue 9886.

• Export an algorithm to skip the active transition when the page is hidden. See issue 9543.

• Use snapshot containing block when capturing new state for document element. See issue #10177.

• Fix algorithm for dispatching updateDOMCallback promise.

• Scope view transition names to matching tree context. See issue 10145.

• Fix scoping to match name instead of element. See issue 10145.

• Add a rendering characteristics note about out-of-viewport elements. See issue 8282.

• Swap the order of invoking the update callback and setting the phase. See issue 10822.

Changes from 2022-05-25 Working Draft

• Fix typo in ::view-transition-new user agent style sheet. See PR.

Changes from 2022-11-24 Working Draft

• Pointer events resolve to the documentElement when rendering is suppressed. See issue 7797.

• Add rendering constraints to elements participating in a transition. See issue 8139 and issue 7882.

• Remove html specifics from UA stylesheet to support ViewTransitions on SVG Documents.

• Rename updateDOMCallback to ViewTransitionUpdateCallback. See issue 8144.

• Rename snapshot viewport to snapshot containing block.

• Skip the transition if viewport size changes. See issue 8045.

• Add support for :only-child. See issue 8057.

• Add concept of a tree of pseudo-elements under pseudo-element root. See issue 8113.

• When skipping a transition, the ViewTransitionUpdateCallback is called in own task rather than synchronously. See issue 7904

• When capturing images, at least the in-viewport part of the image should be captured, downscale if needed. See issue 8561.

• Applying the ink overflow to the captured image is implementation defined, and doesn’t affect the image’s natural size. See issue 8597.

• Fragmented elements don’t participate in view transitions. See issue 8339.

• Rename "snapshot root" to "snapshot containing block", and make it an absolute positioning containing block and a fixed positioning containing block for its descendants. See issue 8505.

Changes from 2022-10-25 Working Draft (FPWD)

• Add dynamic view transition style sheet concept for dynamically generated UA styles scoped to the current Document.

• Add snapshot viewport concept. See issue 7859.

• Clarify timing for resolving/rejecting promises when skipping the transition. See issue 7956.

• Elements under a content-visibility:auto element that skips its contents are ignored. See issue 7874.

• UA styles on the pseudo-DOM stay in sync with author DOM for any developer observable API. See issue 7812.

• Suppress rendering during updateCallback. See issue 7784.

• Changes in size/position of elements in the new Document generate new UA animation keyframes. See issue 7813.

• Scope keyframes to user agent stylesheets using -ua- prefix. See issue 7560.

• Update pseudo element names to view-transition*. See issue 7960.

• Update selector syntax for pseudo-elements. See issue 7788.

• Add sections for security/privacy considerations.