[css-view-transitions-2] Abort transition if the navigation takes too long

[khushalsagar]

This came up on the TAG review. If the navigation is taking longer than a certain threshold, it's better to just show the new content directly instead of running an animation. The exact time can be left to the UA.

[vmpstr]

If it's possible, I'd like to generalize this to allow the UA to skip the transition if it decides that the transition effect would contribute to a worse user experience rather than skipping it.

I think we can provide guidance, such as some timeout, but there may be other situations where the transition might not make sense. For example, if for whatever reason the UA clears the visual buffer of the previous page, but the new page hasn't loaded yet, then it might not make sense to do a transition.

[khushalsagar]

Yeah, there are other cases where skipping makes sense. I'd prefer for the spec to list out the conditions where the UA is advised to skip instead of a generic, "if you think it would contribute to a worse user experience". For example, #8953 says that the UA should skip if its doing its own transition. Feel free to file issues for any other cases you have in mind.

if for whatever reason the UA clears the visual buffer of the previous page, but the new page hasn't loaded yet, then it might not make sense to do a transition.

When would this happen?

[vmpstr]

When would this happen?

Correct me if I'm wrong, but I don't think the spec (html or css) is opinionated whether the visual buffer has to remain uncleared for any duration. This is the reason why I think listing out explicit condition when the UA is advised to skip the transition is insufficient, since it would imply that other situations have to have a transition. I don't think we'd be able to list all possible situations because at least some would be implementation dependent

[khushalsagar]

Correct me if I'm wrong, but I don't think the spec (html or css) is opinionated whether the visual buffer has to remain uncleared for any duration.

We had a resolution for this at #8888. The browser has to retain the contents of the old Document in the visual buffer until the new Document renders a frame when there is a transition.

But now that you brought it up, I can think of one edge case where it might not be possible: "the process where the old Document's cached rendering was stored crashes". We can add spec text to say, "If the browser can not retain content from the old Document, the transition should be skipped" with a non-normative note clarifying this situation as an example for when that would happen. Does that suffice?

[fantasai]

@khushalsagar Might want to treat that as a transition from a blank/unknown URL rather than blocking the transition entirely. I think it's a bit of a separate question from whether it's taking too long to load the page.

[khushalsagar]

Might want to treat that as a transition from a blank/unknown URL rather than blocking the transition entirely. I think it's a bit of a separate question from whether it's taking too long to load the page.

There's a couple of cases for slow loads where we might want a different strategy:

• The server took too long to respond. In these cases we leave the current Document interactive, because the server response might cancel the navigation (like a 204). In the meantime the user can still interact with the page or hit the stop button.

  I don't know if we want to start the timer for "slow load" until we have a server response. The fact that the current page is interactive/animating makes me think not. But I might be biased because I want more transitions. ^_^

• The server has responded, we've unloaded the old Document and the visual buffer is showing last paint of old content until the new Document is ready. So there are no animations in the page content and user input doesn't work. At some point the browser has to clear the visual buffer (so the user understands that the new page is loading).

  This scenario lines up with your thinking of: "I think it's a bit of a separate question from whether it's taking too long to load the page". It's conceptually similar to the problem in [css-view-transitions-2] Should ViewTransition on cross-document navigations allow entry animations #8791 perhaps. If we don't have any state from the old Document then its basically the new Document doing a bunch of entry animations on a blank tab.

[vmpstr]

I suspect going into detail about every possible situations where a transition should be skipped might imply that all other situations must have a transition, and that may not be possible now or in the future, depending on the situation.

A simple example is something like a UA defined transition on regular navigation. AFAIK, no major browser has this type of a transition, and it's not in the spec, but requiring a view transition in this case might be wrong if some browser does implement a default transition and runs it instead of the view transition.

So the carve out I'm suggesting is to say that ultimately the choice whether to run the transition is up to the UA. It should make all effort to do so, but in situations that doing such a transition will certainly result in a worse user experience, it should skip it.

Or do you believe that we should make the effort in the spec to outline every situations in which a transition must be skipped?

[khushalsagar]

So the carve out I'm suggesting is to say that ultimately the choice whether to run the transition is up to the UA. It should make all effort to do so, but in situations that doing such a transition will certainly result in a worse user experience, it should skip it.

I'm just not sure how vague we want to leave this. For example, I like the resolution we had on #8953. It clearly states that UAs can abort the view transition if they provided their own transition, but doesn't specify in what cases UAs can do their own transition.

I'd be ok with the wording you mentioned as well, would prefer that we at least document the conditions for aborting as we find them. As non-normative recommendations for implementors and to ensure reasonable interop.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Abort transition if the navigation takes too long, and agreed to the following:

• RESOLVED: Specify that UAs MAY skip a VT for any reason, give an informative list of examples where they might do so (taking too long, etc)

The full IRC log of that discussion

<TabAtkins> khush: This came up during TAG review
<TabAtkins> khush: If you click the link, and it spins for 5s, do you really want a transition or do you just want to display the page directly?
<TabAtkins> khush: Interesting question.
<TabAtkins> khush: Proposal is, when you initiate nav the browser starts timing. If the render time crosses a threshold, browser SHOULD consider aborting the transition.
<TabAtkins> khush: So how specific should we be in the normative text of the spec?
<zcorpan> q+
<TabAtkins> khush: We ahve some text about browser-provided transitions being skipped, but doesn't say in what conditions the browser should provide that or skip non-browser transitions
<TabAtkins> khush: Should we just say "browser MAY" and then informatively list some exapmles?
<fantasai> yes
<TabAtkins> khush: So first resolution is to cancel transition if it's taking too long
<astearns> ack zcorpan
<TabAtkins> zcorpan: I think you should normatively say "UA MAY skip the VT for any reason" and then ahve examples
<TabAtkins> zcorpan: I don't think we should try to foresee all possible reasons for canceling
<vmpstr> +1
<TabAtkins> khush: I'm happy with that
<TabAtkins> astearns: Do we need a MUST for delay?
<TabAtkins> TabAtkins: I think like font timeouts it's fine as a quality-of-implementation issue
<TabAtkins> astearns: So resolution is "may skip for any reason", with a list of examples.
<TabAtkins> RESOLVED: Specify that UAs MAY skip a VT for any reason, give an informative list of examples where they might do so (taking too long, etc)