View Transitions API

[khushalsagar]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Shared Element Transitions
• Specification or proposal URL: https://drafts.csswg.org/css-shared-element-transitions-1/
• Explainer URL: https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

The spec still has some open issues but the overall feature design is concrete at this point. Also here is the chrome status entry.

[khushalsagar]

A few other relevant links:

TAG review: w3ctag/design-reviews#748
Webkit RFP: WebKit/standards-positions#48

[bgrins]

Hi @khushalsagar! There's a lot to digest here, so I think it will take us some time to form a position. But a couple of us took a look and I wanted to share some first impressions.

These are important use cases, so appreciate the effort put towards it and I can tell a lot of thought has been put into it. But I have to admit I'm finding it fairly complex to learn. I don't know yet if it's just because the problem is complex, or if there are any ways to simplify it and still solve the most important use cases.

My primary questions are around the end-user experience on MPAs - as it's listed as a top use case, it's where new capabilities are being introduced, and (AIUI) it hasn't been prototyped yet & still has some open questions on the design.

• I'm a little worried about an uncanny valley where these cross document navigations will kinda feel like an app/SPA but just a really slow and unresponsive one. I'm imagining the flow where I click on a link, then wait 100+ ms, then see the transition happen. Will that just feel like a super sluggish animation? I could be wrong about this, but it would be great if there was a relatively cheap way to validate it. Is it possible to simulate the approximate MPA experience in the demo SPA app by i.e. adding latency between renders or something?
• Does this on net increase the amount of time the new page takes to show content to the user? And are there limits to how long we'll wait for a document to render before just giving up? Do we have any ideas from data in the wild on how long on average we expect this to add before the user sees content?
• Any kind of cross origin transition was flagged as a potential privacy concern. I know there are some considerations already in the explainer, but just wanted to note that so that as the same origin cross document API is designed it would be compatible with any restrictions that were placed on cross origin.

Secondarily, I find the use of the large nested pseudo-element trees a little hard to follow. Not saying it's wrong, but I suspect a lot of people will find it non-obvious. I'm curious if other alternatives were explored. For example, putting a UA shadow DOM on the root element and then styling via shadow parts may be a way to avoid exposing the implementation details around nesting and handling deep pseudo trees from selectors. Happy to take that to the repo to discuss in more detail but just wanted to check if there's been prior discussion on that topic before doing that.

[khushalsagar]

Thanks for the feedback @bgrins, appreciate your considerations on this. I have added responses inline below to the questions raised:

I don't know yet if it's just because the problem is complex, or if there are any ways to simplify it and still solve the most important use cases.

The primary goal with the current API has been to layer the feature on top of existing web concepts to make it easy for developers to learn and use the feature. If you have suggestions for any part of the API which could be made simpler, happy to discuss more.

I'm a little worried about an uncanny valley where these cross document navigations will kinda feel like an app/SPA but just a really slow and unresponsive one. I'm imagining the flow where I click on a link, then wait 100+ ms, then see the transition happen. Will that just feel like a super sluggish animation? I could be wrong about this, but it would be great if there was a relatively cheap way to validate it. Is it possible to simulate the approximate MPA experience in the demo SPA app by i.e. adding latency between renders or something?

It’s trivial to simulate a delay with the SPA app, the API allows the developer to control how long to wait for the next page to load before starting the animation. For example, click on any of the thumbnails in the pages below:

• https://deploy-preview-23--http203-playlist.netlify.app/ - 300ms delay
• https://deploy-preview-25--http203-playlist.netlify.app/ - 1000ms delay
• https://deploy-preview-24--http203-playlist.netlify.app/ - 2500ms delay
• https://deploy-preview-26--http203-playlist.netlify.app/ - 4000ms delay

These examples rely on the browser spinner to indicate 'loading', rather than in-page spinners, which would be more 'traditional' for SPAs.

Note: Since these demos are using this feature, you’ll need to load them in Chrome canary and enable chrome://flags/#document-transition.

Does this on net increase the amount of time the new page takes to show content to the user? And are there limits to how long we'll wait for a document to render before just giving up? Do we have any ideas from data in the wild on how long on average we expect this to add before the user sees content?

No, this feature doesn’t add any increase to the amount of time to show the new page (modulo the time for the animation itself). The animation starts with the first frame rendered by the new page.

That said, there is a trade-off between quickly switching to the next page (and loading/rendering incrementally) vs adding a reasonable delay so the next page is ready for a transition. But that tradeoff is there regardless of whether the switch is instant or involves an animation (that this feature adds). Our strategy is to enable devs to make that trade-off for MPAs (similar to SPAs) with independent features that can be combined with this API.

• render-blocking to decide which resources to delay the first frame on. For now we’re using a UA decided aggressive timeout but might make this configurable if a use-case comes up.
• speculation-rules which a developer can use to pre-render the new page. They could choose to limit transitions to pre-fetched pages.

as the same origin cross document API is designed it would be compatible with any restrictions that were placed on cross origin

Makes sense. Our thinking for cross-origin is that it should be a subset of the capabilities for same-origin. For example,

• The animations in the feature have a set of UA defaults which can be overridden by the developer. Cross-origin will be limited to the UA defaults.
• The API allows the incoming page to know which elements were shared by the outgoing page, this information will be hidden in the cross-origin case.

I find the use of the large nested pseudo-element trees a little hard to follow.

We did discuss this internally and the choice was between shadow DOM and pseudo-elements. We didn't want to use the html element directly as the shadow host since this prevents the developer from attaching their own shadow DOM to the root element and creates compat risk. We tried adding a pseudo-element to the html element which could be the shadow host. But that ran into issues with multiple features using flattened tree traversal that don’t expect pseudo-elements to be shadow hosts.

Pseudo-elements proved to be easier to implement and weren't limiting any of the capabilities required. There was already precedent for nested pseudo-elements for marker so any gaps (for instance with better selectors for nested pseudo-elements) would help those use-cases too. The shadow DOM approach required exposing pseudo-element references to developers, so they could customize the animation. So the developer API surface was quite similar for styling the browser generated DOM.

Please do file an issue to discuss this further, particularly if you have concerns that this is a limiting design choice.

[bgrins]

Thank you for the response @khushalsagar, and for taking the time to put together the demo pages with various latencies. That does help illustrate the experience to me - I did a side by side manual test in Chrome stable and canary with the flag on. In these variations where the simulated "new" document is already fully loaded/rendered I think the experience felt nice and avoided the uncanny valley concern I had even with the larger delays. I'll be curious as the prototype advances to see how it feels in actual MPAs and where the new state is progressively rendered (either because resources aren't render-blocking or because it hits a UA timeout). For example, if animating in to a missing or low-res version of an image that's present in the old state.

[bgrins]

Would be interested to hear any other thoughts on the API from @dholbert and @emilio

[emilio]

We did discuss this internally and the choice was between shadow DOM and pseudo-elements. We didn't want to use the html element directly as the shadow host since this prevents the developer from attaching their own shadow DOM to the root element and creates compat risk.

Can you elaborate? <html> can't be a shadow host already, per step 2 of https://dom.spec.whatwg.org/#dom-element-attachshadow. document.documentElement.attachShadow({mode: "open"}) throws on all browsers.

You could argue that pages with JS could make the documentElement a <div>, but...

[bgrins]

We can get a new issue on file in https://github.com/WICG/shared-element-transitions for the shadow parts discussion specifically

[khushalsagar]

Heads up, we'll have a session on this feature at TPAC on Wednesday. I'll post the exact time next week. Looking forward to see folks interested there!

[khushalsagar]

The breakout session is on September 14 at 3 PST. Details are here including a link to join virtually.

[khushalsagar]

We recently discussed the question of shadow DOM vs pseudo-elements at CSSWG here. The resolution was to take the pseudo-element syntax. @bgrins @emilio does that address your concerns on #190?

Also, are there any other design aspects about this feature you'd like to discuss more?

We'd like to make edits to the html spec pertaining to this feature. This includes the change to add render-blocking and transition steps invoked during update the rendering described in the view transitions spec here. Could you please provide Mozilla's position for these changes.

[emilio]

Yeah, I'm ok with the CSSWG resolution regarding syntax.

Reviewing a bit the spec, I'm confused about the second monkey-patch here?

For each Document in docs with a transition suppressing rendering of true:
[nothing]?

I also still think that this should probably not be shipped without the same-origin multi-page support tho. It seems rather unfortunate to provide features for SPAs that MPAs can't support.

[khushalsagar]

Reviewing a bit the spec, I'm confused about the second monkey-patch here?

Ah, that's my bad. The changes under monkey-patches need to go in the html spec. I had opened a PR to land it there, but erring on moving all html specific changes to that spec once the CSS spec has been accepted for CR. Just sent a change to fix the spec text in the CSS spec, feel free to review it.

I also still think that this should probably not be shipped without the same-origin multi-page support tho. It seems rather unfortunate to provide features for SPAs that MPAs can't support.

Completely agreed on the second point, this must be supported for MPA. We're actively working on it, there is a prototype you can try on Chrome canary. Just need to enable view-transition-on-navigation and add the following meta tag to both Documents:

<meta name="view-transition" content="same-origin">

All cross-document same-origin navigations to/from this Document will have a ViewTransition. The CSS is the same as the SPA API for customizing it. The UA CSS is also the same, which is why you get a cross-fade by default. There are also open issues in CSSWG labelled "css-view-transitions-2" to discuss MPA specific parts of this API, like #8048 for this opt-in moving to CSS.

But we don't want to block shipping the SPA API until multi-page support. The feature is already structured to have the same rendering model, and CSS/JS syntax for customization; in both SPA/MPA. The only part specific to MPA is how and which navigations trigger a transition and SPA shipping doesn't need to block on this.

[dholbert]

(note, @khushalsagar sent intent-to-ship for the same-page API, in Chromium/Blink.)

[zcorpan]

We're supportive of View Transitions, but since it's a new capability for MPAs in particular, we think it's important that the solution works well for MPAs and that it's consistent with the solution for SPAs. As such, if design changes are needed for the MPA use case that also affect SPA API, the latter should be updated as appropriate even though it has shipped.

In other words, we think it would be bad for the SPA and MPA APIs to diverge or be inconsistent.

[jakearchibald]

we think it's important that the solution works well for MPAs and that it's consistent with the solution for SPAs. As such, if design changes are needed for the MPA use case that also affect SPA API, the latter should be updated as appropriate even though it has shipped.

Fwiw, we took a break from developing the SPA part of the API to sketch out a bunch of future-features we think we might want as part of view transitions. Eg https://github.com/WICG/view-transitions/blob/main/explainer.md#cross-document-same-origin-transitions and https://github.com/WICG/view-transitions/blob/main/explainer.md#future-work. These sketches are incomplete, and a little out of dates, but we considered their fundamentals when working on the SPA feature.

For example, we technically don't need ::view-transition-image-pair, since the blend mode isolation could be applied to the ::view-transition-group. However, this wouldn't work with nested groups, so we catered for that early-on.

I'm confident we won't need breaking changes to the existing model for MPA, but if we need to, we'll do it.

I think it's more likely that declarative features will be added to support the MPA case, and we add those into the SPA API as enhancements. For example, with MPA, I think we need some higher-level indication of a navigation being back rather than forward/replace. If we add that for MPA, we'll look to add it for SPA too.

Sorry, that's basically a long way of saying "yes I agree".

[noamr]

@zcorpan is this RFP enough for cross-document transitions or should we file a new one?
See new TAG review request

[zcorpan]

This one is sufficient IMO.

[bokand]

@zcorpan - similar question: Chromium's planning to ship some pieces of cross-document view transitions separately - currently up is the pagereveal event - it's specified separately but a dependency of cross-document view transitions (and was part of the explainer and TAG review). Would you prefer to treat it as a separate feature with a new position or should we use the signal here for pagereveal as well?

[bokand]

friendly ping @zcorpan @bgrins - could you help with my question above?

[zcorpan]

@bokand we can include pagereveal in this standards position. Thanks!