Thanks for the feedback! +1 to Noam's comparison with SPAs, its hard for me to tell the difference between an MPA and an SPA site nowadays with all the history and address bar integration.
> The explainer refers to a new attribute for iframes instead of a new element. Can you elaborate on this? Sorry about that, I just rewrote the explainer and it is now up to date. > Side note: can you say more about what "3. The <persistentwidget> element must be attached to the new document before its first render" means? I'm not sure if this is a term of art I'm not aware of, but I'm guessing that this means either the element must either appear in the initial page source or be injected at or before onload() completes or something? Yeah, so for now we don't want the persistent widget to be still alive in the new page without the new page deciding to adopt it yet while the new page has begun rendering. We could explore other timings of when to kill the widget on a same-origin navigation if the new document doesn't want to adopt the persistent widget, or explore other opt-ins to adopt a widget that are less tied to rendering and the correct persistentwidget element being in place. With the current approach in practice, the author should use render blocking to prevent the first render of the new page until the persistent widget is in place in order to guarantee that it won't be killed. The new explainer's "Basic Example" demonstrates this. Thanks, Joey On Thu, Aug 27, 2026 at 1:36 PM Noam Rosenthal <[email protected]> wrote: > On Thu, Aug 27, 2026 at 7:56 PM Dirk Pranke <[email protected]> wrote: > > > > For example, for at least some part of the internet's user base, users > are used to the idea that if you click on a link the entire page is > unloaded and a new page is loaded, and things *aren't* persisted. Given > that, any plans to make it apparent when something is being persisted? > E.g., something showing up in the address bar or something? Otherwise, > users might wonder why something isn't going away when they navigate to a > new page. > > > > [I grant that the intercepting clicks on links and buttons to avoid page > loads, and the use of SPAs and things like `history.pushState()` have long > blurred this line, and that probably another, larger part of the user base > doesn't really understand loading and unloading at all.] > > This is a key point though. SPAs are so ubiquitous in 2026 that the > line is non-existent IMO. People don't expect navigation to reset the > state. > > > > > Perhaps more importantly, I think people may be used to the idea that > navigating does reset state and that navigating away and back from a page > can be used as a way to try and reset things (intentionally). And, this > might break that expectation. Will there be some way to force these things > to be unloaded and destroyed? E.g., a hard refresh? If not, this seems like > this might introduce debuggability problems and make it harder for users to > recover from problems (although I don't know how many people are even aware > of hard refreshes ...). And even if there is, I'm a bit concerned that this > won't be the default. > > Given the above point, I don't think people are used to that idea > anymore. Also things like `localStorage` service workers and other > aspects stay alive on navigations. > I think that the notion that a navigation is a state reset is useful, > but if taken too rigidly, it pushes people towards an SPA architecture > that breaks all these assumptions from the start (SPAs can even > intercept "hard refresh"). > So in this middle-ground architecture, the app state fully resets, but > the chat widget or YouTube video stays alive. I think that's a win > over forcing people into a full-SPA or full-state-resetting-MPA > architecture. > > > > > Going even further, it seems like it might be possible to abuse this, > e.g., to persist invisible iframes that can then track activity across > pages even when the user isn't aware that that's happening. > > > > [Again, I realize that since everything is same-origin, this probably > isn't introducing any new vectors for things that can't already be done, > just with more difficulty, but I'm not sure that tracking easier by default > is a great idea.] > > If you compare with existing MPAs, maybe you're right. Compared to > SPAs, this might not make tracking easier because it allows adopting > an MPA architecture for the rest of the UI. > > > To be clear, I'm not saying this feature is a bad idea. I'm not actually > sure how I feel about it yet. But, I would feel better about it if the > explainer (or something else) addressed these concerns. > > > > Side note: can you say more about what "3. The <persistentwidget> > element must be attached to the new document before its first render" > means? I'm not sure if this is a term of art I'm not aware of, but I'm > guessing that this means either the element must either appear in the > initial page source or be injected at or before onload() completes or > something? > > The first render is well defined in the spec > (https://html.spec.whatwg.org/multipage/browsing-the-web.html#reveal). > It is where we fire the `pagereveal` event. > > > > > Hope this is useful, > > > > -- Dirk > > > > On Wed, Aug 26, 2026 at 2:23 PM Joey Arhar <[email protected]> wrote: > >> > >> Contact emails > >> [email protected] > >> > >> Explainer > >> https://github.com/WICG/persistent-iframes > >> > >> Specification > >> No information provided > >> > >> Summary > >> Persistent widgets are embedded browsing contexts, like iframes, but > they can persist across same-origin navigations without reloading. > Persistent widgets can be used via the <persistentwidget> HTML element. The > <persistentwidget> HTML element takes a src attribute, like an iframe. In > order to make the <persistentwidget> survive a navigation, all of these > conditions must be met: 1. The navigation must be to a same-origin > document. 2. The <persistentwidget> element must have the same src and id > HTML attributes in both documents. 3. The <persistentwidget> element must > be attached to the new document before its first render. > >> > >> Blink component > >> Blink>HTML > >> > >> Web Feature ID > >> Missing feature > >> > >> Motivation > >> Hard navigations of top-level documents result in the destruction of > all the child iframes of those documents. In cases of same-origin > navigations, there's high likelihood that at least some of those iframes > would need to be recreated on the new document. For iframes maintaining > complex client-side state (e.g. chat widgets, media players, collaborative > editing sessions, payment flows, embedded third-party apps), that results > in loss of state and user-visible performance implications. This > significantly disadvantages MPA architectures (that rely on hard > same-origin navigations) compared to SPA architectures, that can > soft-navigate parts of the document while leaving the iframes intact. That > is particularly problematic for the use-case of in-page agents, and runs a > risk of causing web developers to prefer SPAs due to that, despite > potential performance and maintenance costs related to that preference. > >> > >> Initial public proposal > >> https://github.com/WICG/persistent-iframes > >> > >> Goals for experimentation > >> None > >> > >> Requires code in //chrome? > >> False > >> > >> Tracking bug > >> https://issues.chromium.org/issues/537818859 > >> > >> Estimated milestones > >> > >> No milestones specified > >> > >> > >> > >> Link to entry on the Chrome Platform Status > >> https://chromestatus.com/feature/5155555348971520?gate=6206129112743936 > >> > >> This intent message was generated by Chrome Platform Status. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "blink-dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > >> To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJsC353neof5Pau%2BDSAP0F85-oCTizBS8oipsg7PoNRhQ%40mail.gmail.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "blink-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALyq14-_7xRdY9M6Umso9ssg9vi0xWwgp4jaB2R9Yxi7ZK2rZA%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BabawAJyLFsBhH8pYYHDv%2BXGeHSQjcDa4U2npsZ_Orhg%40mail.gmail.com.
