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

I updated my above reply, in case you’re reading email or already read it.

By the way, this is somewhat possible to do with React components.

With React, we can use a “portal” (React.createPortal) to render to any arbitrary element, even one from another window.

The thing is, this works well when

  • not also using custom elements, because they then need to be defined in the child window
  • using a CSS-in-JS styling system which applies all styles via style attributes, that way we don’t need to think about how to copy styles over.
  • Using React components that do not rely on event bubbling (because they stop at the window boundary).

But this still involves opening the window manually, and also spins up a new context, and event bubbling would require more hacking, 3rd party libs like jQuery won’t simply work, etc. It’s just plain difficult.

Could you describe the use cases?

What are the advantages of Gimp’s multi-window mode? Could you share a screenshot?

Here’s a video showing Gimp going from multi-window mode to single-window mode: https://www.youtube.com/watch?v=bsZYBMvSNhw.

The use cases of multi-window applications are already discussed in many other places besides here. This thread is about how to make implementation of multi-window apps easier for HTML developers (regardless what for).

Linux Tomboy is an example of a highly-multi-window app:

The reasons for wanting to make multi-window applications aren’t so relevant, I’m only suggesting that there can be an easy way of doing it.

@simevidas Another example is gmail, it can pop chats out into separate windows:

Obviously there’s ways to make it work with current APIs, but something like what I’m suggesting would make it super easy.

I think that describing the use cases is the most important part of a proposal. I’m trying to understand why a web app would need multiple windows.

1 Like

Not why does a “web app” need windows (they already do by the way). Why does any app need windows.

This simply makes a feature easier to achieve. All the use cases of apps with multiple windows are already in place, and it’d be great to be able to achieve it easily with web tech. (f.e. publishing desktop apps with Electron)

I still don’t understand why a web app wold need multiple windows. If you can explain that, I would appreciate it. Otherwise, I won’t be able to contribute to this discussion anymore.

Hello @simevidas, I posted an example screenshot, above, of a well-known web app with multiple windows.

At work, we are making our 3D editor’s UI panels pop out into separate windows. It’s a web app, written with React and Three.js. It can run in the web, or in Electron as a standalone application.

Making multi-window desktop applications is a valid desire in general, and some devs might choose to make a desktop application using web tech because that generally makes the process easier (except the windowing part can be tricky).

Having an same-document windowing feature would make the dev experience much simpler for certain cases (like popping widgets out into separate windows).

Here are a couple more example use cases:

The way I look at is not “why a web app would need multiple windows”, but “why any app would need multiple windows”. The latter is a question that is already backed by many examples of real-world applications.

Here is my co-worker, with many windows across only a few applications. Multi-windowing is a first-class citizen in his workflow:

The following is a screenshot of a multi-window flow in Gimp (even with multi-window UI turned off). All of Gimp’s dialogs are made with custom windows. In the screenshot, a custom window is opened for saving a file, then a third window is opened for tweaking output parameters before performing the save:

My examples show the generic multi-window need that application developers have, not specific to web technology. Web tech is only one technology, of many, that can be chosen for making applications with. Some technologies have better windowing abilities.

I’m simply suggesting an improvement for existing and valid desires that application developers have, when they choose to make applications with web technology.

@simevidas Here’s some other benefits that multi-windowing can have:

  • A developer who only knows basic HTML and CSS can already make fully-working forms with inputs. Now if they want to stick the forms in a separate window (for whatever reason the application needs windows), they can’t. A simple <window> element could solve the problem.
    • I’ve worked with web designers (HTML/CSS developers with ability to copy/paste jQuery) in design agencies that would simply give up making multi-window applications with the current JS APIs.
  • accessibility: screen readers, search engines, and other devices can easily understand what is happening by reading the HTML/DOM. Content is still reachable even if rendered in another window.

Multi-windowing is already a feature of web applications and applications in general. The goal I have with my suggestion is simply to make the existing possibilities easier to achieve.

Ah, multi monitor. Now I get it. (I only use a laptop, and I never open multiple windows of the same app side by side, so I didn’t think of the possibility of there being multiple monitors.)

From looking at your images, I can see two different scenarios:

  • multiple windows of the same app open on different screens
  • multiple smaller windows of the same app open on the same screen

Regarding the latter scenario, is there really a need for those windows to be actual windows? Can’t they just be elements on the same web page that are styled like windows and have window-like behavior?

In that case, my co-worker (for example) can’t use his OS-level window management.

But it depends on the app needs. A one-time prompt, blocking the underlying app, might make sense in a modal dialog. On the other hand, a UI component that is frequently visited in a separate window could be a different case.

A more complicated example can be a 3D design studio, with many tools. A designer might have multiple monitors, and will want to arrange all the tools in the arrangement that satisfies their workflow. Imagine tools as complicated as Blender or Cinema 4D (which is sort of the type of stuff we’re making, but for a specific industry, and not yet as complicated).

1 Like

I was observing another designer, who uses Adobe tools, and I was observing how she likes to place her tools (f.e. Illustrator panels) in separate windows wherever she wants across her monitors. This is a real thing that people do. I believe I’ve given plenty of valid examples.

What I’m wishing for is an easy way to achieve multi-window applications.

We can already do it currently, but it is currently painful and complicated.

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.