w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.42k stars 652 forks source link

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

Open khushalsagar opened 1 year ago

khushalsagar commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

See more comprehensive example of how to do this in userland: https://github.com/w3c/csswg-drafts/issues/8685#issuecomment-1568164673

khushalsagar commented 1 year ago

The questions to resolve here are:

css-meeting-bot commented 1 year ago

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

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
khushalsagar commented 7 months ago

This is now for adding a reload keyword eventually.