How to make mithril work with View Transition

[zDaleZ]

Hello,

I have been exploring the View Transition API, which simplifies implementing transitions while offering greater controllability compared to the animation techniques provided by Mithril (see Mithril animation). In my experiments, I attempted to hook into m.route.set, m.redraw, and even m.redraw.sync because invoking document.startViewTransition(m.route.set) directly has not proven reliable. This unreliability is due to the fact that m.redraw depends on requestAnimationFrame and lacks a mechanism to indicate its status, causing the view transition to begin before the redraw cycle has fully completed.

The tests I conducted indicate that this hooking approach does not produce the intended effect. Even if it were to work sporadically, it would not serve as a reliable solution in a production environment. Would you consider modifying m.route.set and m.redraw to return a promise, or help finding another temporary hook method to ensure Mithril's compatibility with the View Transition API?

Thank you for your time and consideration.

[dead-claudia]

What does your code look like so far? I've looked into it myself for how integrating with the view transitions API might look like, but I never dug deep enough to come up with anything concrete so far.

[dead-claudia]

I think I found the issue: they want us to schedule the DOM changes inside the callback instead of inside the animation frame callback.

And unfortunately, we don't allow that level of customization right now. (Nobody does, actually.)

[dead-claudia]

I have a feeling that API is actually targeted towards framework devs and they just aren't making that clear.

In https://drafts.csswg.org/css-view-transitions-1/#separating-transitions, that kind of sudden snap seems like it'd actually make sense absent specific CSS. What does your CSS look like?

Edit: it doesn't. And such a snap sounds like a browser bug or maybe spec bug. https://drafts.csswg.org/css-view-transitions-1/#ua-styles

[zDaleZ]

@dead-claudia

I think I found the issue: they want us to schedule the DOM changes inside the callback instead of inside the animation frame callback.

And unfortunately, we don't allow that level of customization right now. (Nobody does, actually.)

Change DOM outside the callback is possible. requestAnimationFrame be blocked is because of the pause of render cycle during document.startViewTransition. It pauses render cycle, so no frame updates happen. (That's why setTimeout works, perhaps)

[zDaleZ]

The sudden snap is the result of failure of transition. Even if we don't add any CSS, a default cross-fade animation happens.

I learned that some frameworks just use the sync method as callback for View Transition. And I know a delayed-redraw is always better for performance. But in this case, the "bad" sync way is actually better than the new.

Add support of View Transition is not meaning that we should break the async way of redrawing. Instead, it's a new option that available alongside the old way. The old way can keep its behavior, but we add a new logic for the new case.

[zDaleZ]

See also chrome for developers, listed how some framework can adapt with this API.

[zDaleZ]

Hey @dead-claudia, I've seen your issue. You could contact chrome team at the same time, to find if there's still a chance to adapt.

[dead-claudia]

A question: how will we deal with requestAnimationFrame? Since we've known it is blocked during capture cycle, what will become the new scheduler function?

That was what my comment was about. The scheduler function would need to be document.startViewTransition for those transitioning redraws.

[zDaleZ]

If you mean m.redraw.transition(), I understand. I refers to m.redraw(), or m.redraw.transition() will not lay m.redraw() internally?

[dead-claudia]

If you mean m.redraw.transition(), I understand. I refers to m.redraw(), or m.redraw.transition() will not lay m.redraw() internally?

m.redraw.transition() would call document.startViewTransition(m.redraw.sync) like m.redraw() calls requestAnimationFrame(m.redraw.sync). It'd also cancel any pending requestAnimationFrame call.

[zDaleZ]

The shim object would look like this:

In addition, the polyfill is better to be implemented like this:

var p = m.redraw()
return {
    ready: Promise.reject(new Error("View Transition is not available on this browser.")),
    finished: p,
    updateCallbackDone: p,
    skipTransition: function() {},
}

ready can't be resolved when a view transition hasn't actually happened. The callback of ready can be used with web animations api to create advanced animation for pseudo elements, but they never be available in this case.
No worries about things the error will cause. Even the real view transition can throw error. Just believe the others will catch and handle the error.

[dead-claudia]

ready can't be resolved when a view transition hasn't actually happened. The callback of ready can be used with web animations api to create advanced animation for pseudo elements, but they never be available in this case.

No worries about things the error will cause. Even the real view transition can throw error. Just believe the others will catch and handle the error.

The idea is to stick with the "purely additive" idea. If it's present, you get a transition. If it's absent, your code wouldn't break.

Also, I'd rather not be spamming everyone's web consoles and error reporting endpoints with unhandled rejection events every navigation over an expected condition.