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

<window> element demo (same-document same-context windows)

trusktr
2020-05-24

I made an initial proof of concept demo that shows the idea for https://discourse.wicg.io/t/3556

Things to try:

  • Toggle the window open or closed with the button.
  • Close the window with OS-native close button.
  • Click on the div while the window is closed (see the console).
  • Click on the div while the window is open (see the console).
  • While in devtools, try adding and removing the open attribute.
  • While the window is open, try removing the <window> element in devtools.

This concept shows the basic idea, though it is missing some features:

  • the demo only emulates a basic click event, which bubbles up from inside the <window> in the main window DOM.
    • A native solution would naturally support all events
    • For the “polyfill” we would need to emulate the rest of them too.
    • For the “polyfill” we will need to track the coordinates of the events within the window, and then map those back to elements in the main DOM to figure out which elements an event happened on. This could get tricky. It’s probably easy in the native implementation (at least, not any more difficult than the existing native implementation of events DOM as we currently know it).
  • The rendering is done with a canvas within the opened window, using the trick (from the html2canvas lib) of sticking a foreignObject element inside an <svg> element, placing a copy of the DOM there, getting the pixel data from the SVG, then sending it to the canvas. This has limitations: for example cross-origin content won’t render without CORS settings, and not all CSS properties are supported (f.e. no transform or even basics like box-shadow).
    • A native implementation would not have rendering limitations.

But the bottom line is, it paints a picture of how easy it could be to write multi-window applications using elements all in the same DOM. It makes things very easy.

The first 30 lines of code show what a developer could do with the new <window> element; showing how easy it would be to listen to events within the same DOM, without the complexities of cross-window communication, without the complexities of having to determine how to inject CSS into the window, without the complexities of having to figure out how to map events from child window to parent window, etc.

In the native implementation, there would be no JavaScript context or DOM inside the window. The opened window would be only a rendering facade for the elements inside the <window> element. The developer does everything to the window and widow’s content from the main window’s DOM.

All within a single React application (or Angular/Vue/Svelte application) the develop can easily write windowed applications using a single DOM. It’s just super easy!

This does add any inherently new functionality for end users of an application, it just makes the developer experience easier while the end user may not see any difference. This is similar to how APIs like document.querySelector and customElements.define have helped developers accomplish things more easily than before while not necessarily lending to a new type of experience for the end users of a developer’s product.

What are your thoughts on same-document same-context windows with an element like <window>?