1. Introduction
This section is non-normative.
View Transitions, as specified in [css-view-transitions-1], is a feature that allows developers to create animated transitions between visual states of the document.
Level 2 extends that specification, by adding the necessary API and lifecycle to enable transitions across a same-origin cross-document navigation, as well as a few additions that make it easier to author pages with richer view transitions.
Level 2 defines the following:
-
Cross-document view transitions, including the @view-transition rule and the algorithms that enable the cross-document view transition lifecycle.
-
Selective view transitions, a way to match styles based on the existence of an active view transition, and more specifically based on the active view transition being of a certain type.
-
Sharing styles between view transition pseudo-elements, a way to declare a style once, and use it for multiple view transition pseudo-elements. This includes the view-transition-class property, and additions to named pseudo-elements
2. Cross-document view transitions
2.1. Overview
This section is non-normative.
2.1.1. Activation
With same-document view transitions, the author starts a view transition using JavaScript, by callingstartViewTransition
.
In cross-document view transition, what triggers a view transition is a navigation between two documents, as long as the following conditions are met:
-
Both documents are of the same origin;
-
The page is visible throughout the entire course of the navigatiion;
-
the navigation is initiated by the page, e.g. by clicking a link or submitting a form, or is a
traverse
navigation (back/forward). This excludes, for example, navigations initiated by the URL bar; -
the navigation didn’t include cross-origin redirects; and
-
both documents opted in to cross-document view transitions, using the @view-transition rule.
See the lifecycle section for more details.
2.1.2. Waiting for the new state to stabilize
In same-document view transitions, the author can indicate when the new state of the transition is in a stable state by using the callback passed tostartViewTransition
.
Since cross-document view transitions are declarative, there is no such explicit promise. Instead, the user agent relies on the render-blocking mechanism to decide when the document has reached a stable state.
In this way, the author can use the the blocking
attribute, to delay the transition until:
-
All expected scripts are executed, by using the script’s
blocking
attribute on required scripts. -
All expected styles are executed, by using the style or link’s
blocking
attribute on required styles. -
All expected HTML elements are seen by the parser, using an
expect
HTMLLinkElement
element.
Note: overusing the render-blocking mechanism could make it so that the old state remains frozen for a long time, resulting in a jarring user experience. To avoid this, it’s advised to ensure that the render-blocking elements are available in a timely manner.
In this example, the last frame of the old document will be shown, and the animation will be delayed, until all the following conditions are met:
-
style.css
is applied, to ensure the new state has the correct styles -
fixup.js
is run, to ensure the presentation is up to date with script-based fixups. -
The
main-article
section is seen and parsed, to ensure enough of the content is loaded before allowing the transition to proceed.
<!DOCTYPE html> < html > < head > < !-- This will be render-blocking by default -->< link rel = "stylesheet" href = "style.css" > < !-- Since this script fixes up the layout, marking it as render blocking will ensure it's run before the view transition is activated -->< script async href = "fixup.js" blocking = "render" ></ script > < !-- Wait until the main-article element is seen and fully parsed before activating the transition -->< link rel = "expect" href = "#main-article" blocking = "render" > </ head > < body > < header > ...</ header > < main > < article id = "main-article" > ...</ article > </ main > < article id = "secondary-article" > ...</ article > </ body > </ html >
2.1.3. Customization
TheViewTransition
object enables customizing the transition in script.
Same-document view transitions use a single ViewTransition
object returned from the startViewTransition
call for the entire lifecycle.
Cross-document view transitions have two ViewTransition
objects, one in the old document and one in the new document.
2.1.3.1. Handling the view transition in the old document
The pageswap
event is fired at the last moment before a document is about to be unloaded and swapped by another document.
It can be used to find out whether a view transition is about to take place, customize it using types
, make last minute changes to the captured elements, or skip it if necessary.
The PageSwapEvent
interface has a viewTransition
object, which would be non-null when the navigation is eligible to a view transition,
and a activation
object, providing handy information about the navigation, like the URL after redirects.
The transition’s finished
promise can be used for cleaning up after the transition, in case the document is later restored from BFCache.
2.1.3.2. Handling the view transition in the new document
The pagereveal
event is fired right before presenting the first frame of the new document.
It can be used to find out if the view transition is still valid, by querying the viewTransition
attribute.
Similar to a same-document view transition, the author can now select different types
, make last minute changes to the captured elements, wait for the transition to be ready
in order to animate it, or skip it altogether.
2.1.4. Lifecycle
This section is non-normative.
A successful cross-document view transition goes through the following phases:
-
In the old
Document
:-
The user initiates a navigation, by clicking a link, submitting a form, pressing the browser’s back button, etc.
Note: some navigations do not trigger a view-transition, e.g. typing a new address in the URL bar.
-
When the new
Document
is ready to be activated, thepageswap
event is fired. -
If the navigation is same origin, has no cross-origin redirects, and the old
Document
has opted in to cross-document view transitions, the event’sviewTransition
attribute would be aViewTransition
object. -
The author can now customize the transition, e.g. by mutating its
types
, orskip
it altogether. -
If the
ViewTransition
is not skipped, the state of the old document is captured. -
The navigation proceeds: the old
Document
is unloaded, and the newDocument
is now active.
-
-
Then, in the new
Document
:-
When the new
Document
is ready for its first rendering opportunity, an event namedpagereveal
is fired on the newDocument
, with aviewTransition
attribute. -
This
ViewTransition
's
promise is already resolved, and its captured elements are populated from the oldupdateCallbackDone
Document
. -
This is another opportunity for the author customize the transition, e.g. by mutating its
types
, orskip
it altogether. -
The state of the new document is captured as the "new" state of the transition.
-
From this point forward, the transition continues in a similar fashion to a same-document transition, as per activate view transition.
-
2.2. Examples
Instead, we opt in to triggering view-transitions on navigation in both page 1 and page 2:
// in both documents:@view-transition { navigation : auto; }
A link from page 1 to or from page 2 would generate a crossfade transition for example 1. To achieve the effect examples 2, 3 & 4, simply put the CSS for the pseudo-elements in both documents.
@view-transition { navigation : auto; } @media ( max-width:600 px ) { navigation : none; }
-
Opt-in to navigation-triggered view-transitions in both pages.
-
Pass the click location to the new document, e.g. via
sessionStorage
. -
Intercept the
ViewTransition
object in the new document, using thepagereveal
event.
In both pages:
@view-transition { navigation : auto; }
In the old page:
addEventListener( 'click' , event=> { sessionStorage. setItem( "lastClickX" , event. clientX); sessionStorage. setItem( "lastClickY" , event. clientY); });
In the new page:
// This would run both on initial load and on reactivation from BFCache. addEventListener( "pagereveal" , async event=> { if ( ! event. viewTransition) return ; const x= sessionStorage. getItem( "lastClickX" ) ?? innerWidth/ 2 ; const y= sessionStorage. getItem( "lastClickY" ) ?? innerHeight/ 2 ; const endRadius= Math. hypot( Math. max( x, innerWidth- x), Math. max( y, innerHeight- y) ); await event. viewTransition. ready; // Animate the new document's 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' , pseudoElement: '::view-transition-new(root)' } ); })
In the old page:
window. addEventListener( "pageswap" , event=> { // For example, the page was hidden, or the navigation is cross-document. if ( ! event. viewTransition) return ; // If you don't want view transition for back/forward navigations... if ( event. activation. navigationType=== "traverse" ) { event. viewTransition. skipTransition(); } const newURL= new URL( event. activation. entry. url); if ( newURL. pathname=== "/details" && thumbnail. complete) { thumbnail. classList. add( "transition-to-hero" ); // This will cleanup the state if the page is restored from BFCache. event. viewTransition. finished. then(() => { thumbnail. classList. remove( "transition-to-hero" ); }); } });
In the new page:
window. addEventListener( "pagereveal" , event=> { // For example, the page was hidden, the navigation is cross-document, or the transition was skipped in the old document. if ( ! event. viewTransition) return ; const oldURL= new URL( navigation. activation. from . url); if ( newURL. pathname=== "/list" ) { event. viewTransition. types. add( "coming-from-list" ); // This will show the thumbnail until the view transition is finished. if ( ! hero. complete) { setToThumbnail( hero); event. viewTransition. finished. then(() => { setToFullResolution( hero); }) } } });
2.3. Opting in to cross-document view transitions
2.3.1. The @view-transition rule
The @view-transition rule is used by a document to indicate that cross-document navigations
should setup and activate a ViewTransition
.
The @view-transition rule has the following syntax:
@view-transition { <declaration-list> }
The @view-transition rule accepts the navigation and types descriptors.
Note: as per default behavior, the @view-transition rule can be nested inside a conditional group rule such as @media or @supports.
When the @view-transition rule changes for Document
document, the user agent must update the opt-in state for outbound transitions given document.
Note: this needs to be cached in the boolean because the result needs to be read in parallel, when navigating.
2.3.2. The navigation descriptor
Name: | navigation |
---|---|
For: | @view-transition |
Value: | auto | none |
Initial: | none |
The 'navigation' descriptor opts in to automatically starting a view transition when performing a navigation of a certain type. Must be present on both the old and new document.
- none
-
There will be no transition.
- auto
-
The transition will be enabled if the navigation is same-origin, without cross-origin redirects, and whose
NavigationType
is-
traverse
, or -
push
orreplace
, with user navigation involvement not equal to"browser UI"
.
Note: Navigations excluded from auto are for example, navigating via the URL address bar or clicking a bookmark, as well as any form of user or script initiated
reload
. -
2.3.3. Accessing the @view-transition rule using CSSOM
The CSSRule
interface is extended as follows:
partial interface CSSRule {const unsigned short = 15; };
VIEW_TRANSITION_RULE
The CSSViewTransitionRule
represents a @view-transition rule.
enum {
ViewTransitionNavigation ,
"auto" }; [
"none" Exposed =Window ]interface :
CSSViewTransitionRule CSSRule {readonly attribute ViewTransitionNavigation ; [
navigation SameObject ]readonly attribute FrozenArray <CSSOMString >; };
types
3. Selective view transitions
3.1. Overview
This section is non-normative.
For simple pages, with a single view transition, setting the view-transition-name property on participating elements should be sufficient. However, in more complex scenarios, the author might want to declare various view transitions, and only run one of them simultaneously. For example, sliding the whole page when clicking on the navigation bar, and sorting a list when one if its items is dragged.
To make sure each view transition only captures what it needs to, and different transitions don’t interfere with each other, this spec introduces the concept of active types, alongside the :active-view-transition and :active-view-transition-type() pseudo-classes.
:active-view-transition matches the document element when it has an active view transition, and :active-view-transition-type() matches the document element if the types in the selectors match the active view transition's active types.
The ViewTransition
's active types are populated in one of the following ways:
-
Passed as part of the arguments to
startViewTransition(callbackOptions)
-
Mutated at any time, using the transition’s
types
-
Declared for a cross-document view transition, using the types descriptor.
3.2. Examples
document. startViewTransition({ update: updateTheDOMSomehow, types: [ "slide-in" , "reverse" ]});
This will activate any of the following selectors:
:root:active-view-transition-type ( slide-in) {} :root:active-view-transition-type ( reverse) {} :root:active-view-transition-type ( slide-in, reverse) {} :root:active-view-transition-type ( slide-in, something-else) {} :root:active-view-transition{}
While starting a transition without providing transition types, would only activate ':active-view-transition'':
document. startViewTransition( updateTheDOMSomehow); // or document. startViewTransition({ update: updateTheDOMSomehow});
/* This would be active */ :root{ } :root:active-view-transition{} /* This would not be active */ :root:active-view-transition-type ( slide-in) {} :root:active-view-transition-type ( any-type-at-all-except-star) {}
3.3. Selecting based on the active view transition
3.3.1. The :active-view-transition pseudo-class
The :active-view-transition pseudo-class applies to the root element of the document, if it has an active view transition.
The specificity of an :active-view-transition is one pseudo-class selector.
An :active-view-transition pseudo-class matches the document element when its node document has an non-null active view transition.
3.3.2. The :active-view-transition-type() pseudo-class
The :active-view-transition-type() pseudo-class applies to the root element of the document, if it has a matching active view transition. It has the following syntax definition:
:active-view-transition-type(<custom-ident>#)
The specificity of an :active-view-transition-type() is one pseudo-class selector.
An :active-view-transition-type() pseudo-class matches the document element when its node document has an non-null active view transition, whose active types contains at least one of the <custom-ident> arguments.
3.4. Changing the types of an ongoing view transition
The ViewTransition
interface is extended as follows:
[Exposed =Window ]interface {
ViewTransitionTypeSet setlike <DOMString >; }; [Exposed =Window ]partial interface ViewTransition {attribute ViewTransitionTypeSet ; };
types
The ViewTransitionTypeSet
object represents a set of strings, without special semantics.
Note: a ViewTransitionTypeSet
can contain strings that are invalid for :active-view-transition-type, e.g.
strings that are not a <custom-ident>.
The types
getter steps are to return this's active types.
3.5. Activating the transition type for cross-document view transitions
The types descriptor
Name: | types |
---|---|
For: | @view-transition |
Value: | none | <custom-ident>+ |
Initial: | none |
The 'types' descriptor sets the active types for the transition
when capturing or performing the transition, equivalent to calling startViewTransition(callbackOptions)
with that types
.
Note: the types descriptor only applies to the Document
in which it is defined.
The author is responsible for using their chosen set of types in both documents.
4. Sharing styles between view transition pseudo-elements
4.1. Overview
This section is non-normative.
When styling multiple elements in the DOM in a similar way, it is common to use the class attribute: setting a name that’s shared across multiple elements, and then using the class selector to declare the shared style.
The view transition pseudo-elements (e.g. view-transition-group()) are not defined in the DOM, but rather by using the view-transition-name property. For that purpose, the view-transition-class' CSS property provides view transitions with the equivalent of HTML classes. When an element with a view-transition-name also has a view-transition-class value, that class would be selectable by the pseudo-elements, as per the examples.
4.2. Examples
< div class = "box" id = "red-box" ></ div > < div class = "box" id = "green-box" ></ div > < div class = "box" id = "yellow-box" ></ div >
div.box{ view-transition-class : any-box; width : 100 px ; height : 100 px ; } #red-box{ view-transition-name : red-box; background : red; } #green-box{ view-transition-name : green-box; background : green; } #yellow-box{ view-transition-name : yellow-box; background : yellow; } /* The following style would apply to all the boxes, thanks to 'view-transition-class' */ ::view-transition-group ( *.any-box) { animation-duration : 1 s ; }
4.3. The view-transition-class property
Name: | view-transition-class |
---|---|
Value: | none | <custom-ident>+ |
Initial: | none |
Applies to: | all elements |
Inherited: | no |
Percentages: | n/a |
Computed value: | as specified |
Canonical order: | per grammar |
Animation type: | discrete |
The view-transition-class can be used to apply the same style rule to multiple named view transition pseudo-elements which may have a different view-transition-name. While view-transition-name is used to match between the element in the old state with its corresponding element in the new state, view-transition-class is used only to apply styles using the view transitionpseudo-elements (::view-transition-group(), ::view-transition-image-pair(), ::view-transition-old(), ::view-transition-new()).
Note that view-transition-class by itself doesn’t mark an element for capturing, it is only used as an additional way to style an element that already has a view-transition-name.
- none
-
No class would apply to the named view transition pseudo-elements generated for this element.
- <custom-ident>+
-
All of the specified <custom-ident> values (apart from none) are applied when used in named view transition pseudo-element selectors. none is an invalid <custom-ident> for view-transition-class, even when combined with another <custom-ident>.
Note: If the same view-transition-name is specified for an element both in the old and new states of the transition, only the view-transition-class values from the new state apply. This also applies for cross-document view transitions: classes from the old document would only apply if their corresponding view-transition-name was not specified in the new document.
4.4. Additions to named view transition pseudo-elements
The named view transition pseudo-elements (view-transition-group(), view-transition-image-pair(), view-transition-old(), view-transition-new()) are extended to support the following syntax:
::view-transition-group(<pt-name-and-class-selector>) ::view-transition-image-pair(<pt-name-and-class-selector>) ::view-transition-old(<pt-name-and-class-selector>) ::view-transition-new(<pt-name-and-class-selector>)
where <pt-name-selector> works as previously defined, and <pt-name-and-class-selector> has the following syntax definition:
<pt-name-and-class-selector> = <pt-name-selector> <pt-class-selector>? | <pt-class-selector> <pt-class-selector> = ['.' <custom-ident>]+
When interpreting the above grammar, white space is forbidden:
-
Between <pt-name-selector> and <pt-class-selector>
-
Between any of the components of <pt-class-selector>.
A named view transition pseudo-element selector which has one or more <custom-ident> values in its <pt-class-selector> would only match an element if the class list value in named elements for the pseudo-element’s view-transition-name contains all of those values.
The specificity of a named view transition pseudo-element selector with either:
-
a <pt-name-selector> with a <custom-ident>; or
-
a <pt-class-selector> with at least one <custom-ident>,
is equivalent to a type selector.
The specificity of a named view transition pseudo-element selector with a * argument and with an empty <pt-class-selector> is zero.
5. Extending document.startViewTransition()
dictionary {
StartViewTransitionOptions UpdateCallback ?=
update null ;sequence <DOMString >?=
types null ; };partial interface Document {ViewTransition startViewTransition (optional (UpdateCallback or StartViewTransitionOptions )= {}); };
callbackOptions
startViewTransition(callbackOptions)
are as follows:
-
Let updateCallback be null.
-
If callbackOptions is an an
UpdateCallback
, set updateCallback to callbackOptions. -
Otherwise, if callbackOptions is a
StartViewTransitionOptions
, then set updateCallback to callbackOptions’supdate
. -
If this’s active view transition is not null and its outbound post-capture steps is not null, then:
-
Let preSkippedTransition be a new
ViewTransition
in this’s relevant realm whose update callback is updateCallback.Note: The preSkippedTransition’s
types
are ignored here because the transition is never activated. -
Skip preSkippedTransition with an "
InvalidStateError
"DOMException
. -
Return preSkippedTransition.
Note: This ensures that a same-document transition that started after firing
pageswap
is skipped. -
-
Let viewTransition be the result of running the method steps for
startViewTransition(updateCallback)
given updateCallback. -
If callbackOptions is a
StartViewTransitionOptions
, set viewTransition’s active types to a clone oftypes
as a set. -
Return viewTransition.
6. Algorithms
6.1. Data structures
6.1.1. Additions to Document
A Document
additionaly has:
- inbound view transition params
-
a view transition params, or null. Initially null.
- can initiate outbound view transition
-
a boolean. Initially false.
Note: this value can be read in parallel while navigating.
6.1.2. Additions to ViewTransition
A ViewTransition
additionally has:
- active types
-
A
ViewTransitionTypeSet
, initially empty. - outbound post-capture steps
-
Null or a set of steps, initially null.
6.1.3. Serializable view transition params
A view transition params is a struct whose purpose is to serialize view transition information across documents. It has the following items:- named elements
-
a map, whose keys are strings and whose values are captured elements.
- initial snapshot containing block size
-
a tuple of two numbers (width and height).
6.1.4. Captured elements extension
The captured element struct should contain these fields, in addition to the existing ones:- class list
-
a list of strings, initially empty.
6.2. Resolving the @view-transition rule
Document
document:
Note: this is called in both the old and new document.
-
If document’s visibility state is "
hidden
", then return "skip transition
". -
Let matchingRule be the last @view-transition rule in document.
-
If matchingRule is not found, then return "
skip transition
". -
If matchingRule’s navigation descriptor’s computed value is none, then return "
skip transition
". -
Assert: matchingRule’s navigation descriptor’s computed value is auto.
-
Let typesDescriptor be matchingRule’s types descriptor.
-
If typesDescriptor’s computed value is none, then return a set « ».
-
Return a set of strings corresponding to typesDescriptor’s computed value.
6.3. Setting up the view transition in the old Document
6.3.1. Check eligibility for outbound cross-document view transition
Document
oldDocument, a Document
newDocument, a NavigationType
navigationType, and a boolean isBrowserUINavigation:
Note: this is called during navigation, potentially in parallel.
-
If the user agent decides to display an implementation-defined navigation experience, e.g. a gesture-based transition for a back navigation, the user agent may ignore the author-defined view transition. If that is the case, return false.
-
If oldDocument’s can initiate outbound view transition is false, then return false.
-
If navigationType is
reload
, then return false. -
If oldDocument’s origin is not same origin as newDocument’s origin, then return false.
-
If newDocument was created via cross-origin redirects, then return false.
-
If navigationType is
traverse
, then return true. -
If isBrowserUINavigation is true, then return false.
-
Return true.
6.3.2. Setup the outbound transition when ready to swap pages
Document
oldDocument,
a Document
newDocument, and proceedWithNavigation, which is an algorithm accepting nothing:
Note: This is called from the HTML spec.
-
Assert: These steps are running as part of a task queued on oldDocument.
-
If oldDocument’s can initiate outbound view transition is false, then return null.
-
Let transitionTypesFromRule be the result of resolving the @view-transition rule for oldDocument.
-
Assert: transitionTypesFromRule is not "
skip transition
".Note: We don’t know yet if newDocument has opted in, as it might not be parsed yet. We check the opt-in for newDocument when we fire the
pagereveal
event. -
If oldDocument’s active view transition is not null, then skip oldDocument’s active view transition with an "
AbortError
"DOMException
in oldDocument’s relevant Realm.Note: this means that any running transition would be skipped when the document is ready to unload.
-
Let outboundTransition be a new
ViewTransition
object in oldDocument’s relevant Realm. -
Set outboundTransition’s active types to transitionTypesFromRule.
Note: the active types are not shared between documents. Manipulating the
types
in the new document does not affect the types in newDocument, which would be read from the types descriptor once newDocument is revealed.Note: the
ViewTransition
is skipped once the old document is hidden. -
Set outboundTransition’s outbound post-capture steps to the following steps given a view transition params-or-null params:
-
Set newDocument’s inbound view transition params to params.
Note: The inbound transition is activated after the dispatch of
pagereveal
to ensure mutations made in this event apply to the captured new state. -
Call proceedWithNavigation.
-
-
Set oldDocument’s active view transition to outboundTransition.
Note: The process continues in perform pending transition operations.
-
The user agent should display the currently displayed frame until either:
-
The
pagereveal
event is fired. -
its active view transition's phase is "
done
".
Note: this is to ensure that there are no unintended flashes between displaying the old and new state, to keep the transition smooth.
-
-
Return outboundTransition.
6.3.3. Update the opt-in flag to reflect the current state
Document
document:
-
If document has been revealed, and the result of resolving the @view-transition rule is not "
skip transition
", then set document’s can initiate outbound view transition to true. -
Otherwise, set document’s can initiate outbound view transition to false.
6.3.4. Proceed with navigation if view transition is skipped
ViewTransition
transition:
-
If transition’s outbound post-capture steps is not null, then run transition’s outbound post-capture steps with null.
Note: This is written in a monkey-patch manner, and will be merged into the algorithm once the L1 spec graduates.
6.3.5. Proceed with cross-document view transition after capturing the old state
Document
document:
-
If document’s active view transition is not null and its outbound post-capture steps is not null, then:
-
Assert: document’s active view transition's phase is "
pending-capture
". -
Let viewTransitionParams be null;
-
Set document’s rendering suppression for view transitions to true.
Though capture the old state appears here as a synchronous step, it is in fact an asynchronous step as rendering an element into an image cannot be done synchronously. This should be more explicit in the L1 spec.
-
Capture the old state for transition.
-
If this succeeded, then set viewTransitionParams to a new view transition params whose named elements is a clone of transition’s named elements, and whose initial snapshot containing block size is transition’s initial snapshot containing block size.
-
Set document’s rendering suppression for view transitions to false.
-
Call transition’s outbound post-capture steps given viewTransitionParams.
-
Note: This is written in a monkey-patch manner, and will be merged into the algorithm once the L1 spec graduates.
6.4. Activating the view transition in the new Document
Document
document:
-
Assert: document is fully active.
-
Assert: document has been revealed is true.
-
Update the opt-in state for outbound transitions for document.
-
Let inboundViewTransitionParams be document’s inbound view transition params.
-
If inboundViewTransitionParams is null, then return null.
-
Set document’s inbound view transition params to null.
-
If document’s active view transition is not null, then return null.
Note: this means that starting a same-document transition before revealing the document would cancel a pending cross-document transition.
-
Resolve @view-transition rule for document and let resolvedRule be the result.
-
If resolvedRule is "
skip transition
", then return null. -
Let transition be a new
ViewTransition
in document’s relevant Realm, whose named elements is inboundViewTransitionParams’s named elements, and initial snapshot containing block size is inboundViewTransitionParams’s initial snapshot containing block size. -
Set document’s active view transition to transition.
-
Resolve transition’s update callback done promise with undefined.
-
Set transition’s phase to "
update-callback-called
". -
Set transition’s active types to resolvedRule.
-
At any given time, the UA may decide to skip the inbound transition, e.g. after an implementation-defined timeout. To do so, the UA should queue a global task on the DOM manipulation task source given document’s relevant global object to perform the following step: If transition’s phase is not "
done
", then skip the view transition transition with a "TimeoutError
"DOMException
. -
Return transition.
6.5. Capturing the view-transition-class
-
Set capture’s class list to the computed value of element’s view-transition-class.
Note: This is written in a monkey-patch manner, and will be merged into the algorithm once the L1 spec graduates.
Privacy Considerations
This specification introduces no new privacy considerations.
Security Considerations
To prevent cross-origin issues, at this point cross-document view transitions can only be enabled for same-origin navigations. As discussed in WICG/view-transitions#200, this still presents two potential threats:
-
The cross-origin isolated capability in both documents might be different. This can cause a situation where a
Document
that is cross-origin isolated can read image data from a document that is not cross-origin isolated. This is already mitigated in [[css-view-transitions-1#sec], as the same restriction applies for captured cross-origin iframes. -
A same-origin navigation might still occur via a cross-origin redirect, e.g.
https://example.com
links tohttps://auth-provider.com/
which redirects back tohttps://example.com/loggedin
.This can cause a (minor) situation where the cross-origin party would redirect the user to an unexpected first-party URL, causing an unexpected transition and obfuscating that fact that there was a redirect. To mitigate this, currently view transitions are disabled for navigations if the
Document
was created via cross-origin redirects. Note that this check doesn’t apply when theDocument
is being reactivated, as in that case the cross-origin redirect has already taken place.Note: this only applies to server-side redirects. A client-side redirect, e.g. using [^meta/http-equiv/refresh^], is equivalent to a new navigation.
-
This feature exposes more information to CSS, as so far CSS was not aware of anything navigation-related. This can raise concerns around safety 3rd-party CSS. However, as a general rule, 3rd-party stylesheets should come from trusted sources to begin with, as CSS can learn about the document or change it in many ways.
See Issue #8684 and WICG/view-transitions#200 for detailed discussion.