A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[idea] Same-DOM <iframe>-like element

trusktr
2020-09-11

This idea is similar to my idea in [proposal] Same-document same-context windows, declaratively via HTML <window> element.

This idea differs in that we can code the content in an iframe-like element from the same DOM where we are using the iframe-like element.

For the sake of example, let’s call it <frame>.

Usage:

<div>
  The following content is rendered in a separate frame:
  <frame>
    <div id="divInsideFrame">Content in a frame</div>
  </frame>
</div>
<script>
  // The content is written in the same DOM where the <frame> is used,
  // so we can reference it and modify the content within the outer context:
  const div = document.querySelector('#divInsideFrame')
  div.style.background = 'cornflowerblue'
</script>

What this does:

  • Renders the child DOM of the <frame> element inside an iframe-like container/context
  • Any styling (CSS) and rendering (f.e. canvas 2d or webgl) is scoped inside of the iframe-like context.
  • If any graphics crash, browsers can limit the crash to this frame (and perhaps browsers can put a “refresh” button on it) without crashing the whole tab. This can be useful for sites like http://codepen.io, https://www.shadertoy.com, etc.

I’m not sure about the following, but perhaps the <frame> has its own JavaScript context, and the user can launch specific scripts in that context that can not access the outer context. f.e.:

<div>
  The following content is rendered in a separate frame:
  <frame>
    <div>Content in a frame</div>
  </frame>
</div>
<script>
   document.querySelector('frame').runScript('http://some.script/to/run.js') // or something
</script>

That script

  • can access only the DOM that is being rendered in the frame.
  • can access attributes and props on those elements, which means the script can access content provided by the outer context, via Proxy Membrane.
  • can even use getComputedStyle to see what styles are applied from the outer context
  • can not access everything from the outer context, because the Proxy Membrane prevents certain properties from being reachable.

Again, I’m not sure about the <frame> elements having a (somehow-secure while the DOM comes from the outside) JS context in them.

Maybe it would work the same way as when passing nodes from an outer context to the inner context, in that the inner context can gain access to a lot of things from the outer context.

Maybe it would be fine for same-origin code.

But the main idea is that some things like graphics (CSS, canvas, webgl) can be isolated in terms of how the browser renders those parts (separate process, f.e.).

It some ways, it would be similar to a container element in place of the <frame> having style contain: strict; overflow: hidden; or similar, but with additional separation.

Maybe the <window> idea in the other thread can have a similar separate-JS-context type of thing too.

Somnid
2020-09-14

Sounds like this: Use <iframe> contents if srcdoc is present but empty