[css-view-transitions-2] UAs should show loading indicators when waiting for response

[khushalsagar]

This came up on the TAG review. The transition flow for cross-document navigations leaves the current Document in-place until there is a response from the server for the new Document. The user can keep interacting with the old Document until this time.

We should add a non-normative note that the UA should start their loading indicators (most likely do so already) while we're waiting for a server response on the navigation (which will trigger the capture for transition).

[vmpstr]

Should this be a normative SHOULD note instead?

[Que-tin]

Should there maybe be a pseudo-class to indicate that the new document is loading to enable pre-view-transition animations or custom loaders? But there would need to be UA styles to make sure a loading indicator is shown in case no custom logic is implemented.

[khushalsagar]

Should there maybe be a pseudo-class to indicate that the new document is loading to enable pre-view-transition animations or custom loaders?

@noamr @domenic FYI. If there was such a class (or media-query like primitive), when would you expect it to stop applying so the loading indicator goes away. When the document does its first render, the load event fires, something else. Intuitively, load event makes sense. I think loading indicators in browser UI also stop when this event is fired.

But there would need to be UA styles to make sure a loading indicator is shown in case no custom logic is implemented.

Loading indicators by the browser are generally outside Document scope, so they're drawn irrespective of the page content. For example the loading bar or spinner in browser UI.

[domenic]

If there was such a class (or media-query like primitive), when would you expect it to stop applying so the loading indicator goes away. When the document does its first render, the load event fires, something else. Intuitively, load event makes sense. I think loading indicators in browser UI also stop when this event is fired.

I tend to agree. Although another approach, which might be better, is to tie the pseudo-class explicitly to the browser loading indicator. The difference is that in cases where we give control over the loading indicator, such as with the existing navigation API for same-document navigations, or with new APIs such as whatwg/html#9090 / WICG/navigation-api#256 (comment) for cross-document navigations, the pseudo-class would follow the modified timing, instead of following the load event.