Thanks for the feedback everyone! > I don't actually see the words "first render" in that spec (or anywhere else in the HTML standard), but I do see "during the first `update the render` step" in a Note, so I'm guessing that's what you're referring to. Maybe the text should say "before the pagereveal event first" or "before the first `update the render` step that display up-to-date content", or the text should explicitly define "first render" as that?
Thanks, I updated the explainer to link to the revealing concept. I'm sure that this will be ironed out in significant detail when we get to the point of speccing this feature if we do end up sticking with the first render as the time to discard unadopted persistent widgets. > Do you match based on path alone or the complete URL, including URL decorations (like query parameters with `?` and `&` and section specifiers `#`) or some other excerpt from it? Is Persistent Widget capable of using `<a href="#section">` to link to a different section within it (and if so, how that affects the matching key)? Thanks for asking! I haven't put much thought into this question yet. My gut feeling is that we should make query parameters affect unique-ness, and the URL hash or section specifier (#) should not, but I'd love to hear more opinions on this. > While id is supposed to be unique, web developers occasionally break this rule and have duplicate ids, so how does browser resolve contention between multiple attachment points with the same match key and multiple widgets with the same match key? Duplicating these IDs sounds like an author error to me, so I suspect it might be best to not load duplicate widgets with colliding id+url combinations and emit a helpful console message. I'm also not certain that using the id attribute is going to be the best solution, we could also use the name attribute, come up with a new attribute, or drop the attribute entirely and just say that a matching url is enough to persist a widget. What do you think would be good? > Could you please flash out a bit more how Persistent Widgets integrate with back-forward cache (BFCache) The idea with BFCache is that we want to make sure that a host/embedding document which uses a persistent widget doesn't become disallowed from entering BFCache. > closed tab/window restoration (Ctrl+Shift+T)? When closing and then restoring a window with ctrl+shift+T, I don't think that the widget should be persistent and reloaded through that somehow. > The process of navigating forward is mentioned in explainer: the widget is never part of the host document, so when user navigates forward from host document A to host document B gets detached from A and re-attached to B, unless B failed to load, in which case widget is still attached to A. Is the process of backward navigation the same (with the only exception that document restored from BFCache never fails to load)? Yes, I believe that backward navigation should work the same as forward navigation in this case. > What if current document and a prerendered document have attachment points with the same key? Since widget can not be detached from the currently visible document, then it can not be attached to prerendered document, so it prerendered document creates a separate instance of the widget. It sounds like we should avoid loading persistent widgets during prerendering in the case that the current document has a matching persistent widget. Would that address this case? Thanks, Joey On Fri, Aug 28, 2026 at 6:57 AM Noam Rosenthal <[email protected]> wrote: > On Fri, Aug 28, 2026 at 8:45 AM Anton Bershanskyi <[email protected]> > wrote: > > >>> 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"). > >> > >> > >> Really? How? Via a service worker or by intercepting a key stroke? Even > if they can, it seems like doing so might be a bad idea, UX-wise ... > > Sorry, it can intercept programattic calls to `navigation.reload()` > (which is also something I'd like to reconsider tbh. I think reloads > should be only a browser UI thing) > What I said earlier was inaccurate. Retracting my last parenthetical > (though the rest of the argument stands) > > >> > >> I don't actually see the words "first render" in that spec (or anywhere > else in the HTML standard), but I do see "during the first `update the > render` step" in a Note, so I'm guessing that's what you're referring to. > Maybe the text should say "before the pagereveal event first" or "before > the first `update the render` step that display up-to-date content", or the > text should explicitly define "first render" as that? > > Sure, the explainer can probably be more explicit about that. > Deferring that to @Joey Arhar. > -- 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%2BmMx3YbK%2BRjMnkas%3Du4iDc%2BALmifD-U4RJfM-qA2oiWg%40mail.gmail.com.
