Frames

what about the concept of an "inline" layer?

This feature is one of my biggest ambitions and also my personal nemesis. I have spent more time thinking about this than any other feature. There have been 5 attempts to design an API for this, and 2 abandoned implementation attempts.

I'm currently working on more managable things, but here are my incomplete thoughts for anyone interested:

What content can be shown in a frame?

The most ambitious layer feature was that multiple copies of an web app can run on multiple layers, and that content does not need to know whether they're used on the root page, or in an overlay.

I think the same should apply here. Any content that can now be loaded into an overlay should also be containable by a frame.

Can we use frames for subinteractions?

I think so, for the same reason.

We would need to decide what happens when a frame is accepted or dismissed. We cannot "close" a frame like we do with overlays. A default behavior may be to restore their original content. We might need a way to override this default.

Can frames be nested?

Probably? Otherwise we would have rules about what kind of content works in a frame.

Is there isolation between frames?

I think so. A frame shouldn't be able to accidentally see or change elements from another frame unless explicitly stated with an [up-frame] attribute or similar.

I'm not sure whether is ever necessary to target arbitrary frames on the layer (through a selector?), or only its parent and children. Probably the latter?

Is there isolation between nested frames?

Child frames shouldn't be able to accidentally see or change elements from their parent frame unless explicitly stated with an [up-frame] attribute or similar.

I'm undecided whether parent frames should be able to see elements from their children. If we isolate children from their parents in both directions, the child frame's element itself must still be part of the parent frame, or the parent could never delete a child frame from itself.

Is any layer automatically considered a "frame"?

Probably?

Can frames update history?

Probably not, unless the frame is itself a layer?

Must frame containers have unique selectors?

No, this would violate the ambition to use any content for a frame or layer. It should be possible to load any selector into a frame, or to use default main targets when no selector is given.

This is currently not possible with Turbo Frames, where each frame needs a unique ID and every response must contain a <turbo-frame> with that exact ID.

How would a JavaScript API to work with frames look like?

We would at least need functions to:

• Accept a frame
• Dismiss a frame
• Emit an event on the frame
• Listen to events on the frame

How does this affect existing APIs?

Frame isolation would affect all functionality that works with selectors and elements. So pretty much everything. Solving this requires a huge design and implementation effort.

When layers were introduced I went to every single function and thought how they should work with layer isolation. In most cases the new behavior I decided on was:

• Every function only sees elements from up.layer.current by default. When we look up a selector or traverse the DOM in any way, elements from other layers are ignored.
• We go to great lengths to ensure up.layer.current is always set to the right layer, even when things are happening in a background layer.

This allowed us to keep simple APIs like up.reload('.list').

However, we cannot easily have a similar function up.frame.current because there may always be multiple frames on the current layer. Any function would need a reference element to know which frame we're talking about.

While we do have a reference element when the user follows an a[up-follow] or submits an form[up-submit], JavaScript functions that take a selector don't. It's unclear what a statement like up.reload('.list') would do. It would also be a shame to lose the conciseness of such APIs and force users to use up.reload('.list', { origin: someElementILookedUp }) everywhere.

Lots of soul searching required here.

Can we have a pretty and unified APIs that works for both layers and frames?

I haven't come up with one, but I think we need this. Content should not need to know whether it's running on the root page, in an overlay, or in a frame. E.g. if the user asks to accept or dismiss the current "scope" it should accept either layer or frame.

On the Javascript I'm unsure whether this could all be merged into the up.layer API or if we would have multiple modules for this. It would be great to discover a unified API and not overload users with more concepts. On the other hand, frames have some fundamental differences to layers, like requiring a reference element and being a tree, not a stack. I haven't yet come up with a unified API that isn't overy abstract.

Lots of soul searching required here.

Alternatives to frames

Of course it might be that I'm missing something and this is already possible!

A similar feature is that fragment placement considers interaction origin. For example:

1. You have a screen with 100 <div class="card"> elements
2. You click a link within the 37th card
3. The server returns a new <div class="card">
4. The 37th card is replaced with the new content, leaving the 99 other cards unchanged

It's not isolated like layers are, but for some use cases it's enough. I used this heavily in the demo's task list.

Lazy-loading content

I was originally going to propose a feature, something like "up-lazy" or "up-deferred", where an element could be marked as immediately triggering a second request to the server on page load.

I think this would be a great addition which I've often implemented through custom compilers.

Unpoly usually attempts to retain basic functionality without JavaScript, so this would probably look like a link that follows itself automatically. Something like this?

<div class="menu">
  <a href="/expensive-menu" up-autofollow up-target=".menu">Menu</a>
</div>  

Maybe such an link would replace its own element if no [up-target] is given?

It should also be possible to delay loading until the frame scrolls into the viewport. I think htmx and Turbo can do this.