[csswg-drafts] [css-view-transitions-2] Timing for checking at-rule (#9867)

khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-view-transitions-2] Timing for checking at-rule ==
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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9867 using your GitHub account


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

Received on Friday, 26 January 2024 21:14:20 UTC