[proposal] Same-document same-context windows, declaratively via HTML <window> element

Two similar use cases

  1. List HTML <video> element (Web Media Player application within browser source code) as an Application (window) when getDisplayMedia() is executed https://bugzilla.mozilla.org/show_bug.cgi?id=1574662, https://bugs.chromium.org/p/chromium/issues/detail?id=994953;
  2. Picture-In-Picture window is listed as an Application at getDisplayMedia() though the specification recommends to set maximum pixel dimensions to screen.width/2, where the width and height can be extended to remove limit on the width and height of PictureInPictureWindow https://github.com/w3c/picture-in-picture/issues/163

The concept of Picture-In-Picture window could potentially be utilized for this proposal.

Re the linked SO questions and example code at [proposal] Same-document same-context windows, declaratively via HTML <window> element see

1 Like

Thanks for posting. Those StackOverflow questions are good at showing that multi-window development is a bit tricky at the moment.

Here’s an idea.

Note the new CSS contain property.

Now suppose, for this new <window> feature, the content inside the <window> element is rendered as if it is in a container with contain: strict.

Then, just imagine that the browser simply renders the content of the <window> inside an OS-level window.

This seems like an easy way to describe the implementation. It is simple: the <window> content size is determined by the external OS window (and the OS window size may be determined by attributes on the <window> element), and the content renders just as if that content were inside a contain: strict parent. The browser simply then places those pixels in the OS window. Seems simple!


I have an idea for a prototype. We can use html2canvas for rendering the content in the OS window.

In the main DOM, we would write

<window width="1024" height="768">
  <div>This content renders into an external OS window!</div>
</window>

Then the “polyfill” would take the DOM tree of the <window> element, maybe duplicates it, sizes it off screen to the size of the window, and finally runs it through html2canvas to get pixels, and finally sends those pixels to the other window to draw them in a <canvas>.

This would be neat. The DOM that the user cares about would be in the main window’s DOM, and the rendering is abstracted away and gets piped to the OS window.

html2canvas covers most of the use cases of HTML (I believe it is limited to whatever HTML rendering that SVG supports), so this prototype would work for many cases but not all like a native implementation would.

Of course some things would need implementation, like piping events from the OS window back to the main windows for things like clicks, touches, etc. We’d want those events to bubble through the original DOM, not the prototype’s OS window DOM which is basically just a canvas. This part would get a little tricky, and is the sort of thing that would be perfect to abstract in a native implementation.

This prototype would be a fun hackathon for a day or two!

The Window Placement API as mentioned in this thread introducing it will help improve window.open for Progressive Web Apps.

To carry out the work of this “element that creates a new facade window but everything is still controlled over in the main window” I’d really want some compelling use-cases. What needs to be done that window.open with the ability to talk across the windows can’t achieve? Beyond some level of scripting simplification Are there any benefits to end users that they can’t get otherwise?

It is a ton of work, probably well beyond a “day or two hackathon” for a proof of concept unless someone is already very experienced with browser code.

I listed a slew of compelling use cases above. Mostly they are all around developer experience and making multi-window applications easy. I’m not saying that multi-window apps aren’t possible, because of course they are. But making multi-window apps is currently very difficult.

I’m just asking for an easy way to do it; and a way that is declarative and therefore jives well with all the existing DOM manipulation tools like React, Angular, Vue, Svelte, and even jQuery.

I believe I described that above. window.open is not declarative, and therefore does not hook into the very popular programming paradigms of today. I also listed above the complications involved with sending CSS from the main window to an opened window (for example). Writing multi-window applications is complicated (please see above, I believe I have covered that in enough detail, but please ask a specific question about it if you have).

There is not: an end user (who merely uses the end product of a developer) won’t know the difference.

Again, this isn’t about what’s possible, this is about making it easier to achieve the same things as we can today in a simpler way, for developers.

There are many features in the web that don’t relate to end users directly. For example, developers can achieve many things without Custom Elements or Shadow DOM, however those developer APIs make it easier to achieve certain things. New CSS features are usually making it easier for developers to achieve things (for example, flexbox vs positioning with percentages, where flexbox allows us to achieve existing possibilities in an easier way).

That proposal is tangential to this one. Both would be useful.

const winElement = document.querySelector('window')
winElement.window.moveTo(...)

Where winElement.window is not a WindowProxy (because there’s no DOM or JS context for that window), but perhaps something like RenderWindow that only has a subset of APIs for moving/sizing/closing/etc.

But the proposal of this thread would also allow:

<window screen-position="300 400">
  <div>I render in the window.</div>
</window>

We could also just set the DOM property:

const winElement = document.querySelector('window')
winElement.position = "300 400"

(cc @msw-google @anssik)

Alright, I made a working prototype (with a subset of the features that the full version would have, see comments, and tested only in Chrome for this round).

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).

It only took me… 6 hours and 6 minutes! That took longer than I thought it would!

The concept shows that the interaction happens with respect to the DOM of the main window. The popup window is only for rendering.

So far, only the click event is emulated. The full implementation would emulate all events, and would detect which element the event happened on based on the event coordinates.

This would be clean and non-hacky in the native implementation.

See the TODO list in the comments.

I hope this shows how the abstraction could make multi-window applications super simple to implement for web developers.