[css-view-transitions-2] Should ViewTransitions be triggered for reloads?

[khushalsagar]

A reload is technically a cross-document same-origin navigation, but its unclear whether authors want a ViewTransition in such cases. One of the sites we're working with mentioned they don't want any animation on reloads.

Note that since the UA CSS does a cross-fade between root images using plus-lighter, that animation is a no-op if there is no change in visual content. But if the site overrides this for a different default (like a slide), they'll need to detect reloads to get back the no-op cross-fade.

We can make this configurable so the author can decide whether reloads from the current Document trigger a ViewTransition.

[noamr]

I think reloads should not be supported. Reload is about starting the page from scratch, it kind of goes against the concept of transitions.

[noamr]

To disable same-page transitions on reload, you can use JS in the head (it's a bit hacky but should give a direction):

if (performance.getEntriesByType("navigation")[0].type ==="reload") {
  document.documentElement.dataset.reload = true; 
}
window.onload = () => {
  document.documentElement.dataset.reload = false; 
}

html[data-reload]::view-transitions {
  display: none;
}

[noamr]

See more comprehensive example of how to do this in userland: #8685 (comment)

[khushalsagar]

The questions to resolve here are:

• Should reloads be supported for View Transitions at all? We can technically do it but it's unclear if this is what authors want. We've heard from authors which were surprised by them (when trying out the prototype in Chromium) and wanted to disable it. But haven't heard from anyone who wants that capability.

• If we do want transitions on reloads but authors should be able to configure them, do they happen by default or not. There is already going to be an opt-in for cross-document View Transitions. It's unclear if this global opt-in enables transitions on all navigation types. Or whether it enables them for every navigation type other than reload and an additional opt-in is required for reloads.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Should ViewTransitions be triggered for reloads?, and agreed to the following:

• RESOLVED: Reloads don't trigger view transitions by default.

The full IRC log of that discussion

<fantasai> noamr: This is about reloads, came up by people using the current experiment we have with cross-document ransitions
<fantasai> noamr: question is what should happen on reloads
<fantasai> noamr: by default, currently, the transition happens
<fantasai> noamr: because it's just a same-origin navigation where both pages opt in!
<fantasai> noamr: but developers find this confusing
<fantasai> noamr: in the future we might want opting in or customizing specifically the reload transition
<fantasai> noamr: which is something we wanted to add to the opt in
<fantasai> noamr: but wanted to say that they're disabled for now
<fantasai> noamr: because more confusing that useful
<astearns> +1 to disabling on reload (by default)
<fantasai> noamr: also thinking about reloads, reloading from cache, things are not always fast when you reload
<fantasai> noamr: also you probably went from some state to same state
<fantasai> noamr: right now is disable by default, opt in if need arises
<astearns> ack fantasai
<emilio> q+
<khush> +1
<fantasai> fantasai: 100% agree about disaling
<astearns> ack emilio
<fantasai> fantasai: also this is something to think about when designing the at-rule
<fantasai> emilio: Wanted to ask about reloads, or navigating to the same URI
<fantasai> emilio: e.g. if you click to the same URI
<fantasai> noamr: related is history
<fantasai> noamr: I think that navigating to the same URI is also like posting a form, for example
<fantasai> noamr: in which case transitions could be useful?
<fantasai> emilio: I'm fine with special-casing reloads
<fantasai> emilio: but seems like other cases to consider
<dbaron> my intuition is that special-casing reloads makes more sense than special-casing same-uri navigation
<fantasai> emilio: e.g. click on GitHub logo from the GitHub homepage. Seems weird to navigate around
<fantasai> khush: wrt navigation, two types, replacing current entry or adding a new entry
<fantasai> khush: so if you have a link to the same page, retrieve that as a new navigation
<fantasai> khush: but if replacing the current entry, then that shouldn't do a transition
<fantasai> emilio: so are you proposing to do reload, or all replacement navigations?
<fantasai> emilio: I think we all agree that reloads shouldn't trigger VT
<fantasai> emilio: but are there other cases?
<fantasai> emilio: e.g. [lists examples]
<fantasai> emilio: question is what specific concepts to use here, though we all seem to agree on disabling reload by default
<fantasai> noamr: [too quiet]
<fantasai> noamr: might be a good starting point
<fantasai> noamr: redirect, like meta refresh
<vmpstr> q?
<fantasai> noamr: is that also a replace?
<fantasai> noamr: client-side redirects
<fantasai> noamr: are also replace
<fantasai> noamr: [missed]
<emilio> examples: clicking on the same page (not a replaced load), explicit replace load via script, ...
<astearns> ack fantasai
<emilio> fantasai: it seems we all agree on reloads
<emilio> ... but we need more exploration for which other cases shouldn't trigger a transition
<emilio> ... e.g. clicking on a fragment adds to history but probably shouldn't transition
<khush> Unless it's cross-doc, we won't do a transition.
<emilio> ... so should we resolve on reloads not doing transitions and investigating other issues in the issue?
<fantasai> astearns: Proposed resolution is reloads don't trigger VT by default, any objections?
<fantasai> RESOLVED: Reloads don't trigger view transitions by default.
<fantasai> ACTION: Investigate other cases that shouldn't trigger view transitions.
<fantasai> astearns: If we disable a bunch of stuff, re-enabling things might be tricky, so need to be careful when categorizing the set of things
<fantasai> astearns: but let's move on