Re: [csswg-drafts] [css-view-transitions-2] How should view transitions be wired up in frame-timed update loops? (#12125)

> > Yea, `popstate`'s sync nature is a bit clunky. the navigation API is a better fit here and is being worked on for interop 2025. Have you considered switching to that?
> 
> Yes, I've looked into it. [It's way too new for us to be depending on it right now](https://caniuse.com/mdn-api_navigation), and I'd prefer to wait for broader compatibility before doing it. (We prioritize stability and compatibility over features - it's one of our selling points. For instance, we only dropped support for IE after Microsoft did.)

Understood. As I said, it's in interop 2025 so it's likely to be implemented in Gecko and WebKit before any other change we propose here.

> Question: are updates held until after the callback resolves or until after the promise resolves?

Until after the promise returned by the update callback resolves.
 
> > Yea, that's unfortunate and requires integration of view transitions into the framework. I think that's a less error prone design than adding lower level knobs to the platform and expecting app developers to tweak all of them correctly.
> 
> IMHO this should've been communicated from the start, that this needed routers to integrate support for it on their end. I would've strongly preferred to receive a feature request citing a blog post saying it needed router integration than to be in this current situation.

I don't think this was well understood at the time of designing this API.  Note that at the time, frameworks like NextJS had lower level events so integration was easier (this was before "app router"). The [blog post you've mentioned](https://developer.chrome.com/docs/web-platform/view-transitions/same-document#working_with_frameworks) was targeted at UI frameworks (React) rather than routers/meta-frameworks (NextJS etc). As the usage evolved we found that there is indeed an integration issue with routers, which usually requires frameworks at that level to integrate view transitions in a built-in way. 

> 
> > What stops you from integrating view transitions into mithril in this way rather than expecting devleopers to integrate it from the outside?
> 
> Ignorance. [The Chromium team's blog post made this seem like something users should be able to just integrate themselves](https://developer.chrome.com/docs/web-platform/view-transitions/same-document#working_with_frameworks), so it seemed like I didn't need to do anything on my end.

OK, what's stopping you now? :)
Designing a low level API that would satisfy all of this is definitely possible but there might not be enough energy behind it yet given the complexity it would entail and differences between browser engines. To clarify: the synchronous snapshot idea in #9400, while theoretically possible, is very complex to implement.

-- 
GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12125#issuecomment-2855665930 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 6 May 2025 19:22:22 UTC