Re: [csswg-drafts] [css-view-transitions-2] Declaring when an MPA transition can start (#8681)

> > It will be set at document initialization and stay there until rendering is unblocked.
> 
> That seems reasonable. I was confused by the naming initially, since 'active' has a wider scope. I think there's a more general feature here around blocking rendering, so I'd advise splitting this into two parts:
> 
> * A way to control render blocking
> * A way to know there's a pending cross-document transition (in case render blocking should be different in that case)
> 
> However, it's worth considering if there are cases where the developer would want to control render blocking when the page is coming out of bfcache.
> 
> > 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?
> 
> This is discussed in #8682. I really recommend catching up with the current state of the design. A lot of this stuff has already been discussed internally and with CSSWG folks like Tab. I'm not saying that the design is perfect, or even good, but I think there's value in at least reading it.

Yea I went through all of it but it's spread over a couple of dozens of issues so I'm sure I missed some points. Will catch up on that one.

> 
> > 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.:
> > ```
> > <head>
> >   <script>
> >   addEventListener('crossdocviewtransition', e => e.waitUntil(new Promise(resolve =>
> >     document.addEventListener("load", loadEvent => {
> >       if (loadEvent.target.id === 'hero')
> >         resolve();
> >     }, {capture: true})));
> >   </script>
> > </head>
> > ```
> 
> Sighhhhh we really should have promises for this stuff.
> 
> > 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.
> 
> But you also don't want transitions that fail or look faulty on certain kinds of traversal, because the developer has to add extra code for bfcache transitions, and they didn't test that bit.
> 
> That said, I agree that in regards to render blocking, what you'd do for initial load is different to coming out of bfcache. I think the best way to approach is to look at render blocking as a more general feature.

Right, this is exactly where I'm at... Before we get to a general-purpose potential-footgun, let's try to fix this more from the use case site and see what the need is afterwards.


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


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

Received on Friday, 26 May 2023 17:35:36 UTC