[css-view-transitions-2] Timing for checking at-rule

[khushalsagar]

The CSS opt-in which decides whether navigating away from a Document will trigger a transition is currently spec'd to be checked at 2 places:

1. When the navigation is initiated. This is being landed in the html spec as a part of sourceSnapshotParams which are cached when the navigation starts: https://github.com/whatwg/html/pull/10002/files#r1464196273. We require it early in the navigation lifecycle for performance reasons.

2. The second spot is here: https://drafts.csswg.org/css-view-transitions-2/#resolve-view-transition-rule-algo:~:text=Resolve%20%40view%2Dtransition%20rule%20for%20oldDocument%20and%20let%20resolvedRule%20be%20the%20result. This runs once we have the final response and before the old Document is unloaded.

I'm not sure doing it at step 2 is a good idea. It'll be racy since the task which runs these steps doesn't have an event which fires before the steps. So there's no way to reliably update the CSS. Also, we're providing an explicit event which has a VT object, the robust way would be to call skipTransition() on it. Having this check could encourage authors to opt-out via CSS after the navigation has been initiated instead of the more reliable event way.

[khushalsagar]

Summary from offline conversation, there's stages in the navigation's lifecycle where we could read the opt-in: when the navigation is initiated and when we have the final response (the navigation is ready to be committed). Ideally we'd use the latter timing to have the most up-to-date preference from the author. For example, if a media query like prefers-reduced-motion changes which opts-out of transitions that should apply.

We have to check the opt-in at the first spot for perf reasons, so the reasonable option would be to keep both. There must be an opt-in at both stages of the navigation for a transition to happen.

Proposed Resolution: A navigation has a transition if there is a cross-document opt-in when the navigation is initiated and when its ready to commit.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Timing for checking at-rule, and agreed to the following:

• RESOLVED: check the at-rule a second time, when the nav is about to commit

The full IRC log of that discussion

<TabAtkins> noamr: into cross-document VTs!
<TabAtkins> noamr: We have @view-transition rule, when it's read we understand the coming navigation should have a VT
<TabAtkins> noamr: right now, the way it's implemented you can say it's read in two places, or in one place
<TabAtkins> noamr: We read it once when the navigation starts
<TabAtkins> noamr: Because if there is no VT going on, we optimize and don't block the old document on anything
<TabAtkins> noamr: we want the nav to go asap
<TabAtkins> noamr: And then, if the at-rule is there, we block the old document, fire an event, etc. capture the documetn state
<TabAtkins> noamr: So what happens between the first check and the second check, if the VT rule changed. JS changed it, it's an MQ that changes etc
<TabAtkins> noamr: Two options. First is use the value at the beginning as the source of truth - animation is already starting
<TabAtkins> noamr: Second is to check again, skip the transition if it's changed to turn off the VT at this point.
<TabAtkins> noamr: Note that at second point we can't *start* a VT if it started false and then became true.
<bramus> TabAtkins: what is the 2nd time?
<TabAtkins> noamr: Right before we fire the pageswap event, we fire it so you can skip the transition. also this i sjust before we capture the snapshots
<TabAtkins> fantasai: between the two check times, is the doc live?
<TabAtkins> noamr: yes
<khush> q+
<miriam> ack fantasai
<TabAtkins> khush: first is when nav is initiated, then while we're waiting for the network response users can still interact with the doc. that's by design
<TabAtkins> noamr: Yeah it can be on the order of several seconds
<miriam> ack khush
<TabAtkins> khush: wanted to mention, the first check has a subtle reason for timing
<TabAtkins> khush: ideal would be to wait for network response and check at that time what the page wants
<TabAtkins> khush: but this is mainly for browser-generated navigations
<TabAtkins> khush: we dont' want to go back and dispatch an event late
<TabAtkins> khush: so now when a nav is started fro mteh browser process we just check immediately
<bkardell_> s/fro mteh/from the
<TabAtkins> khush: I also wanted us to just check once, when initiatied. second spot is a bit racy, unclear when the check happens
<TabAtkins> khush: But good point on MQs, if you're using that do decide animation
<TabAtkins> khush: It's nicer for that to apply if it can, rather than ignoring it and forcing you to do all the conditionality in script
<miriam> q?
<TabAtkins> noamr: So I'd like to propose that we check it twice - I think there's no real downside
<TabAtkins> noamr: It keeps you more correct on what happens to your at-rule. We're already queueing a task to block the doc, might as well check it again.
<miriam> ack fantasai
<TabAtkins> fantasai: I think changes in things like prefers-reduced-motion are so unlikely to not matter
<TabAtkins> fantasai: But MQs against screen size to change the *type* of animation you trigger, that seems mor elikely
<TabAtkins> fantasai: slide vs fade or something
<florian> +1 to fantasai's point
<TabAtkins> fantasai: so it does make sense to re-check. you're still triggering *a* transition, just not sure which type
<khush> +1
<TabAtkins> bramus: typical example would be user rotating their phone from landscape to portrait
<fantasai> s/elikely/likely/
<TabAtkins> noamr: Proposed resolution: check the at-rule a second time, when you're ready to start the transition
<TabAtkins> RESOLVED: check the at-rule a second time, when the nav is about to commit

[noamr]

We already do this.