- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 May 2023 11:02:41 +0000
- To: public-css-archive@w3.org
> I think the problem with that is it's unclear when calling `waitUntil` would work. With the event the rules are simple: If you get the event, you can call `waitUntil` in the same task. > > With your proposal, it's a value that the UA is going to set and unset at some points, and without an event, there's no indication when it'll be set and unset. It will be set at document initialization and stay there until rendering is unblocked. In that sense, there's no difference between calling `activeTransition?.waitUntil(...)` and `addEventListener("crossdocviewtransition", e => e.waitUntil...)`. You have to add the event listener in the head, so might as well `waitUntil` in the head. The same question would apply to "how do you know to add the event listener? Maybe it's already been called" since it's fired very early. > Also, when is it unset? Presumably when the transition stops being 'active', which means `transition.finished`. That means there'll be a period where `document.activeTransition` exists, but `document.activeTransition.waitUntil()` will fail, because the transition has already started. > > There's also an issue with naming. Would `document.startViewTransition` cause a new `document.activeTransition` to be set? If so, what happens with `document.activeTransition.waitUntil`, since that API doesn't make sense on same-document transitions. Also domUpdated doesn't exactly make sense in the MPA case. Perhaps `ViewTransition` could have a subclass/superclass with slightly different properties for MPA vs SPA, because of this? Note that this problem also exists in the event if you want to be able to skip transition. (`event.transition` would not exactly be a `ViewTransition`) We can perhaps call it `pendingTransition`, and it's there only in `head` scripts or in the `pageshow` event. > > If the event is useful for other things, it might be worth using the event for this too, as it doesn't have the above issues. It's useful but it has some gotchas, like what happens if rendering is cached so there's no rendering coming at all. I'm still pursuing it though. One thing I'm *slightly* concerned about with this event is that people would implement it with first-navigation in mind, and then create infinite-wait bugs for reactivate. Let's take the use case of blocking the transition until the hero image has loaded: e.g.: ```html <head> <script> addEventListener('crossdocviewtransition', e => e.waitUntil(new Promise(resolve => document.addEventListener("load", loadEvent => { if (loadEvent.target.id === 'hero') resolve(); }, {capture: true}))); </script> </head> ``` Of course it's simple to fix this, but also easy to overlook this - it would work great when you run it locally, but then when you have BFCache/prerender it would wait forever. What I'm getting at is, I'm not sure we should have an event that abstract away the difference between reactivation and initial render with an event that fires in both. You have an event for the former and the latter is a synchronous script in `head`, and in many cases there would be subtle differences anyway, so might as well deal with them directly rather than pretend that they're the same case. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8681#issuecomment-1562707915 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 25 May 2023 11:02:46 UTC