Portals should load and retain state even when they're not in the document #172
Comments
|
With the exception of the That means that ownership has to be either rooted somewhere that's torn down when the document unloads (e.g. the document, but we could have some other collection that owned "background" portals if we feel that's a substantial ergonomic improvement over the strategy developers are used to) or bounded in time (e.g. lifetime extended until the end of some queued task). |
|
There's a third option: A detached portal could be treated like a bf cache page entry. As in, it goes through the whole But, if we don't care too much about the third use-case, extending lifetime by a task would solve the first two use-cases. |
|
If I were an author, I would find that sometimes my portal reloads when I'm moving it around and sometimes it doesn't somewhat surprising. |
|
I mean we wouldn't discard it while it was still in reference, but we can discard it on GC. At that point you aren't exposing GC, because there aren't any events to fire. I think the one-more-task solution is good enough though. |
|
You could observe whether it had run, which is itself an antipattern, by noticing whether state was preserved. (And in Chromium at least, there is the potential for implementation issues that may make this difficult to collect, because of the possibility of untraced owning references in both directions.) But agreed that we can find some other solution here. |
Sure, but it's how the bfcache works. |
domenic
added
the
design work needed
|
My gut feeling is this would become a point of contention with other browser vendors (and probably implementers in Chrome too). We could close this, and instead go for a general solution whatwg/html#5484. We lose this use-case:
But it's the weakest of the use-cases, and easy to work around. |
|
Generally agreed, except that it's possible whatwg/html#5484 goes nowhere due to complexity around compat and iframe behavior that doesn't apply to portals. |
Iframes reload if they're moved around the DOM, but I don't think the same should happen with portals.
Use-cases:
Imagine a list of article previews, where some/all contain portals to the article. On click, the portal animates to fill the viewport, then it's activated.
Doing this in-place is impossible if any ancestor element has
overflow: hidden. This is likely sinceoverflow: hiddenis used for things like padding/float containment. This CSS will prevent the element filling the viewport.The way this is typically achieved, is to move the element to
<body>, and absolutely position it in its previous place, then it can be animated freely.With an iframe, this would incur a reload, which is undesirable.
Imagine a list of article previews, where some/all contain portals to the article. On click, the portal activates. However, what if the user indicates they want the article to open in a new tab/window?
We already have
window.open, but if the page is already loaded in a portal, we should avoid having to reload it. In this case the developer could open anabout:blankwindow, move the portal to it, and activate it there.Again, iframe-style reloading wouldn't work here.
Imagine a list of article previews, where the first is most-likely to be clicked, so should be preloaded.
Right now, the developer would have to add the portal to the page, position absolute, opacity 0, pointer-events none etc etc just so it actually loads. This feels like a hack.
The portal should load as soon as its src is set, so this sort of preloading doesn't require it being appended to the body.
The text was updated successfully, but these errors were encountered: