- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 18:27:22 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: into cross-document VTs!<br> <TabAtkins> noamr: We have @view-transition rule, when it's read we understand the coming navigation should have a VT<br> <TabAtkins> noamr: right now, the way it's implemented you can say it's read in two places, or in one place<br> <TabAtkins> noamr: We read it once when the navigation starts<br> <TabAtkins> noamr: Because if there is no VT going on, we optimize and don't block the old document on anything<br> <TabAtkins> noamr: we want the nav to go asap<br> <TabAtkins> noamr: And then, if the at-rule is there, we block the old document, fire an event, etc. capture the documetn state<br> <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<br> <TabAtkins> noamr: Two options. First is use the value at the beginning as the source of truth - animation is already starting<br> <TabAtkins> noamr: Second is to check again, skip the transition if it's changed to turn off the VT at this point.<br> <TabAtkins> noamr: Note that at second point we can't *start* a VT if it started false and then became true.<br> <bramus> TabAtkins: what is the 2nd time?<br> <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<br> <TabAtkins> fantasai: between the two check times, is the doc live?<br> <TabAtkins> noamr: yes<br> <khush> q+<br> <miriam> ack fantasai<br> <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<br> <TabAtkins> noamr: Yeah it can be on the order of several seconds<br> <miriam> ack khush<br> <TabAtkins> khush: wanted to mention, the first check has a subtle reason for timing<br> <TabAtkins> khush: ideal would be to wait for network response and check at that time what the page wants<br> <TabAtkins> khush: but this is mainly for browser-generated navigations<br> <TabAtkins> khush: we dont' want to go back and dispatch an event late<br> <TabAtkins> khush: so now when a nav is started fro mteh browser process we just check immediately<br> <bkardell_> s/fro mteh/from the<br> <TabAtkins> khush: I also wanted us to just check once, when initiatied. second spot is a bit racy, unclear when the check happens<br> <TabAtkins> khush: But good point on MQs, if you're using that do decide animation<br> <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<br> <miriam> q?<br> <TabAtkins> noamr: So I'd like to propose that we check it twice - I think there's no real downside<br> <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.<br> <miriam> ack fantasai<br> <TabAtkins> fantasai: I think changes in things like prefers-reduced-motion are so unlikely to not matter<br> <TabAtkins> fantasai: But MQs against screen size to change the *type* of animation you trigger, that seems mor elikely<br> <TabAtkins> fantasai: slide vs fade or something<br> <florian> +1 to fantasai's point<br> <TabAtkins> fantasai: so it does make sense to re-check. you're still triggering *a* transition, just not sure which type<br> <khush> +1<br> <TabAtkins> bramus: typical example would be user rotating their phone from landscape to portrait<br> <fantasai> s/elikely/likely/<br> <TabAtkins> noamr: Proposed resolution: check the at-rule a second time, when you're ready to start the transition<br> <TabAtkins> RESOLVED: check the at-rule a second time, when the nav is about to commit<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9867#issuecomment-1939302384 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 18:27:25 UTC