Public Request for beta-testing of the new docking library.

[evonox]

I am just before finishing the pre-alpha version of the new DockerTS library. Could I ask for the public testing? Pre-alpha demo version of the library you can find at: https://docker.robotkarel.cz/ . If you find any repeatable error scenario, please submit me issue at: https://github.com/evonox/docker . Thank you very much for any support, suggestions or opinions of how to make the new library better. It will be released using MIT license for the benefit of the whole community.

[jogibear9988]

1.) I'd love if you could remove the additional dependencies. We don't use lodash, and it only used for depbounce, throttle and deep, I'd love if it could be removed.
For velocity-animate, I don't know, if it is really needed, but seems not to be a good idea to use a lib wich has no updates since 4 years.
2.) red flicker when I undock: https://app.screencastify.com/v3/watch/w3PNa58cM0HlIxo6oVH0
3.) One major issue: What really will not work for our system, is that you remove elements from dom and add them to other nodes. I changed dock-spawn-ts completely so that the container wich has the user content is never removed or moved to another dom node. Cause if you have really huge pages, this is verry slow. I alwas position them absolutely and only move the dock nodes around
4.) The library should be published as an ESM module. Also the type in the package.json should be set to "module". We have a no build setup, so we include very lib directly as ESM via an importmap, and every javascript library today should be usable in this way
5.) why jquery in docker-ts.js ??

For me it really looks nice, and I'd love to use it, but I can only when the dome nodes will stay in DOM

[evonox]

Dear @jogibear9988 ,
thanks for your comments and suggestions.
I will address your requirements as follows:

1. I understand the need for zero-dependencies. However we need the lodash functions for performance reasons as well as velocity-animate for fast JS animations. However I can address this issues as I will extract those few Lodash functions to my own helper class and remove the dependency. As for the velocity-animate, it is sad this good library is not maintained, I will replace it with my own JS animation framework. I do not write simple JS animation library for the first time. The other benefit for removing the dependencies is that we will decrease the JS bundle size. It is I think around 200kb without CSS which is quite a lot. My dream is to get with JS and CSS to around 50kb gzipped size.
2. I have a question. As you have noticed, I do not download WheelItem images, but inline them inside CSS. Is that ok for you? It has two reason. We reduce the number of HTTP requests the server needs to do and the second, we will have only two files for deployment.....CSS and JS file.
3. I apologize for the red flickering. It is not bug. I just noticed I have deployed the debug version of the library. I use red backgrounds exactly to find out, where the docking library is slow and needs optimizations.
4. I understand the DOM issues. It is one of major tasks that is still awaiting addressing. I will review this issue completely, not only adding DOM nodes but also implementing some diffing algorithms as you have in your DockSpawnTS in SplitterPanels and TabHost.
5. ESM will be created. This demo is just for presentation purposes. The library is not meant as production-ready now. It will take some time.
6. jQuery issue is quite funny. The reason it is there is the originally velocity-animate library was developed to replace slow animations inside jQuery. So this library is detecting if jQuery is downloaded to substitute its original implementation for animations. The sad thing is this library is no longer maintained so we have to remove it. The other argument for removing it is also the bundle size as I have written. I will implement its simplified version and substitute it. We will save a few KBs hopefully.

[jogibear9988]

1.) With brotly it will get much smaller

[evonox]

I think, the next week I could have prepared the beta version that might be a candidate for production-ready version of the library. There is however plenty of things to fix.

[jogibear9988]

Will you also support undock to new window? It would be nice if this could work, also with support of docking back...

Maybe you've seen the support in visual studio code?

[evonox]

@jogibear9988
Do you mean undock to a new browser window? I have it as one of the future features to implement. I want to support also collapsers like wcCabinDocker has and the support for perspectives like in Eclipse IDE. But first I want to publish the docking library quickly to NPM registry to start the public testing completely. By publishing the first version my work on this library is starting, not ending.
By the way, we need to create the new library name. I asked in one FB Czech frontend group for opinions and there was critisism as DockerTS is not a good library name because it is similar to Docker technology which might be a trademark. Do you have any idea how to call it? Maybe I do not mind even if it might have the same name DockSpawnTS.

[jogibear9988]

There are different ways to do it. If you look how I've done it in dock-spawn-ts or how vscode does it. I move the component to the new window. This is very fast. If you look how it works in golden-layout, very slow.
For me it is essential that also web-components with attached stylesheets work, for this I build a hack (if you look at my code (https://github.com/node-projects/dock-spawn-ts/blob/master/src/BrowserDialogHelper.ts). And I've not yet implemented docking back to the origin window.

e could release it as a new version of dock-spawn-ts, I like it, it feels already much more professional. I only did small changes to dockspawn, never did a big rewrite (only the change to keep the nodes in dom).

[jogibear9988]

I've a few more questions:

• Is there a option for every button in the Panels/Dialog? Like IsCloseable, IsMinimizable, .... I think if I use it I will need this to be configurable
• What will the close button do? Remove the content also from DOM or only hide it? Should this be configurable? For example I've tool windows, wich I only create once. You could close the in docksspawn via "x" but I also could show them again.

And you asked about the icons, they are not mine, I used the from the initial dock-spawn project.
But there are also some in https://fonts.google.com/icons?icon.query=dock

[jogibear9988]

I also had a webcomponent wraper for dockspawn, may something like this should also be added, maybe as an extra npm, but in dockspawn it added not much of size, see:
https://github.com/node-projects/dock-spawn-ts/blob/master/src/webcomponent/DockSpawnTsWebcomponent.ts

and most of the code are only api duplications, wich for sure could be done nicer

the main idea was, you could define your docking ui, without any javascript.

[jogibear9988]

I used it the webcomponent for example here: https://node-projects.github.io/web-component-designer-demo/index.html

[evonox]

1. As for the undock / dock feature to new window I will make it one of the priority issues for extension. I want to support anything that is requested and make the library better.
2. Of course, it will be possible to specify if window can be minimized or closed, etc. It will be possible for each panel separately. I am in the process of writing the documentation. I propose we can then discuss the APIs if they are OK for you. By the way, you will have APIs giving you the full controls over the header buttons. You could even add your own custom header buttons. The same is true for the context menus where you will be able to define your own menu items.
3. As for the close button, it will by default remove the panel from the DOM. There will be however an option for Ghost Panels, that will exactly do what you request. They will be hidden by display: none and when you invoke to create such panel, it will just show again. So you could use default behavior or ghost panels upon the scenario you need.
4. The icons you have are fully OK for me. The next week I will have a videocall with my friend who is a graphics designer to discuss default coloring theme, animations, and possibly the icons. I will ask him for his opinion and we will see. The thing I need to mention is that theme of the new library will be fully configured by CSS custom properties, so possible to change in runtime.
5. For the web components, or what I understand as the need for declarative definition of layouts I would propose to take a different approach. I will explain possibly in a PDF document I will include in this discussion thread. Briefly said, the docking library is designed to support micro-frontend applications where one panel could be in React, the second using WebComponents, third VanillaJS or using Vue technology. This does not mean, it is not possible to create declarative definition of layouts. We can use element to specify it. I a bit count on that users of this library will need to use it for large applications composed of multiple micro-frontend frameworks which can be built separately by different teams and deployed separately.

[jogibear9988]

I mean, I'd like a webcomponent version, so the user of the Component does not need to write any line of javascript to use the component. At last it is only a small wrapper for the normal API, but declartively usable. It has nothing to do with the other frameworks, like vue, react,... webcomponents are browser standard, so they work always, if you use a framework or not.
But it can be included later. But don't compare it to angualr, react and vue, cause these are librarys and webcomponent are browser standard

[evonox]

@jogibear9988
Could you please give a proposal of the definition your web components you would like to have? I mean the properties, events, etc. Do you use Lit Framework?

[jogibear9988]

No, i used no framework.
Will do the proposal

[evonox]

Dear @jogibear9988
The second project I have hidden in GitHub private repo is my first attempt to create a pure WebComponent UI library. I use the Lit Framework which is provided by Google. https://lit.dev/docs/getting-started/
As for the WebComponent it saves quite a lot of work. I just send you a link if you want to give it a try.
I have noticed somewhere you create a visual editor and you write you have a base widgets library in Web Components. This is I think our mutual interest and I would love to discuss with you creating a pure Web Component widgets UI library. What do you think?

[evonox]

Dear @jogibear9988
I have a rough implementation of undocking into a popup window and when the popup window is closed, the PanelContainer docks back to its previous position in the main browser window. Hopefully, I will be able to publish another preview with this behavior to test.

[evonox]

Dear @jogibear9988 ,
I need a help from you or anyone other. Now we have a rough implementation of docking to popup windows and today I have added the support of undocking to collapsers moving panels to the left, right and bottom sides. I need now to design an automatic algorithm to dock panel back from these two states. It must be intuitive for the user, that the undocked panel docks back to its previous position even if under the conditions that the docking layout had changed in the meantime. Do you have any idea how to address this issue?

[jogibear9988]

I've no good idea how to dock it back, cause as you said, the docking layout could have changed.
Maybe we allow only to "dock" back as a Dialog?
And also, should we automaticaly dock back when the user closes? For sure, there could be a api to do so, but should it be the standard?

[jogibear9988]

And for webcomponent (means content not the docking library as a webcomponent) support (for those ones wich use adoptedStyleSheets), you also need the parts backupCss and clone of the adopted of my code:

dock-spawn-ts/src/BrowserDialogHelper.ts

Line 50 in 606e2eb

backupSs(element);

Or the controls will have no styles (cause stylesheets are not usable between different browser windows).

And also if you want to support to dock back, the stylesheets need to be cloned again, or switched back to the old ones

[jogibear9988]

if I play arround, I also sometime get this error: https://app.screencastify.com/v3/watch/E3NVxuBi8e3sz2EWwJL2
the drag position is not on the mouse pointer

[evonox]

if I play arround, I also sometime get this error: https://app.screencastify.com/v3/watch/E3NVxuBi8e3sz2EWwJL2 the drag position is not on the mouse pointer

Thank you very much for reporting. It is fixed now.

[evonox]

And for webcomponent (means content not the docking library as a webcomponent) support (for those ones wich use adoptedStyleSheets), you also need the parts backupCss and clone of the adopted of my code:

dock-spawn-ts/src/BrowserDialogHelper.ts

Line 50 in 606e2eb

backupSs(element);

Or the controls will have no styles (cause stylesheets are not usable between different browser windows).
And also if you want to support to dock back, the stylesheets need to be cloned again, or switched back to the old ones

I have written a task to complete adopting CSS stylesheets with the dock / undock operations.

[evonox]

I've no good idea how to dock it back, cause as you said, the docking layout could have changed. Maybe we allow only to "dock" back as a Dialog? And also, should we automaticaly dock back when the user closes? For sure, there could be a api to do so, but should it be the standard?

I have an idea, how to make it pseudo-intuitive, I will come with solution and we will see and discuss it.

[evonox]

I have released a promo / propagation preview version of the docking library at https://docker.robotkarel.cz/
Now the docking library has zero-dependencies which cut down its size decently. However it has still plenty of bugs to be fixed.
Hopefully you like the promo version.

[jogibear9988]

I really like it. I'll look implement it into my designer, so I could see if my scenarios still work.

[jogibear9988]

I also think, the name "docker" is not really good (Cause of the same named container system)

suggestions from chatgpt:
DockJS
SnapDock.js
FlexDock.js
Dockify
DockWizard
Panelli.js
DockMate.js
DockMasterJS
DockFlow.js
Dockster.js

[jogibear9988]

I think we should keep the current dock-spawn-ts, and give yours a new name. I'll then switch mine to "maintenance mode", and link to yours as a successor.

[jogibear9988]

For example, what I also thought to do (but never did) was to implement some sort of Window Stack for popups, means if you open a popup from a popup, I never can be behind this one. But I never did...
But what I have if you open a Dialog from another window, it could grayout the parent:

It's here: http://129.159.205.3:8082/webui/index.html

[jogibear9988]

the header should be scrollable via mousewheel not only via buttons

[jogibear9988]

https://dockview.dev/demo/?theme=dockview-theme-abyss has nice themes, and i like the feature to drag windows into the tabbar directly

[evonox]

Dear @jogibear9988,
thanks very much for your ideas and review. I am now thinking. Should we support undocking to the popup window from other state than a "docked state"? Maybe it makes a sense to me from a floating state possibly, but not minimized, maximized states.

[jogibear9988]

From Floating I think it should be possible, the others I don't think so

[evonox]

I need advice concerning the generated events by the docking library. It is not quite clear to me the meaning of some original DockSpawn events. I also introduce new events as well, because we have many new dockpanel states. The second difference is that my new docking library is generating global and local events. Global events are accessible using the DockManager API and local events for each panel if the change occurred within it. Every panel has its own local interface.

Events

Event	Meaning	Global	Local
onSuspendLayout	???	No	No
onResumeLayout	???	No	No
onDock	Panel is docked	Yes	Yes
onUndock	Panel is undocked	Yes	Yes
onTabReorder	Does it make sense?	No	No
onTabChange	Does it make sense?	No	No
onClosePanel	Panel is closed	Yes	No. Local Panel API has onClose handler
onCreateDialog	Does it make sense?	No	No
onShowDialog	Does it make sense?	No	No
onHideDialog	Does it make sense?	No	No
onChangeDialogPosition	Does it make sense?	No	No
onContainerResized	Does it make sense?	No	No
onActivePanelChange	Panel change ocurred	Yes	No
onActiveDocumentChange	Document change occurred	Yes	No
onActivated	Panel is activated	No	Yes
onDeactivated	Panel is deactivated	No	Yes
onLayoutChanged	Any change to layout	Yes	No
onPinned	Docked from collapser	Yes	Yes
onUnpinned	Undocked to collapser	Yes	Yes
onUndockToPopup	Undocked to Popup Window	Yes	Yes
onDockFromPopup	Docked to Popup Window	Yes	Yes
onMinimized	Panel was minimized	Yes	Yes
onRestored	Panel was restored	Yes	Yes
onMaximized	Panel as maximized	Yes	Yes
onCollapsed	Panel was collapsed in floating state	Yes	Yes
onExpanded	Panel was expanded in floating state	Yes	Yes

May I ask you to review the generated events proposal and give me comments what you think?

[jogibear9988]

For me this looks good.

I think onSuspendLayout and onResumeLayout are used when serializing the layout to json and restoring it from there.

As you may see in the IDE sample of dock-spawn-ts the layout is restored to the state how you configured it last time

[timadevelop]

@evonox @jogibear9988 Hey, thank you for your work, but could you please share why are you working on new solutions while golden-layout / dockview exist?

I guess I need to clarify why I'm asking this question. I'm looking for a docking layout lib for new desktop app we want to build and so far I've came to a conclusion that there are

• dock-spawn-ts - afaiu will go to maintenance mode
• evonox/docker - will replace dock-spawn-ts afaiu
• golden-layout - used by many companies but abandoned, @PerBothner is trying to keep it alive
• dockview by @mathuo - seems like this one starts to gain some traction, afaiu it has touch support and they recently added Vue support
• commercial solutions like jqWidgets , htmlelements, infragistics - paid / closed source / comm license

Looking at all of this, it's crazy hard to make a sane decision about investing into one of them. It seems big companies like Microsoft have developed their own solutions within the product itself (e.g. vscode, even in codesandbox, is pretty good). I'd like to do the same but budgets are not giant for most companies.

So what are the motives behind evonox/docker? Do you have some requirements that are not possible to meet by contributing to other libs?

[jogibear9988]

I use DockSpawn since years. When the initial author dropped support, I converted to typescript.

For me these 2 main features are relevant: Dialogs, keep content in dom

golden-layout did not support dialogs and does not to keep the content in DOM when moving a element.
dockview as I see also does not do both.

And another feature: open in new browser window, is supported by golden-layout, but not via adoptNode, so the whol javascript needs to be loaded again.

If the new one of @evonox will support this I will switch, because it's smaller, cleaner, animates, ....

dock spawn als for example has touch support, don't know if the other two have.

[jogibear9988]

And if you look here:

https://node-projects.github.io/web-component-designer-demo/index.html

you could use dock-spawn-ts complete declaratively (if you use the webcomponent)

[timadevelop]

For me these 2 main features are relevant: Dialogs, keep content in dom
dockview as I see also does not do both.

@jogibear9988 Maybe I do not understand what "Dialogs" means exactly, but doesn't dockview demo cover resizable floating groups and opening them in new window? https://dockview.dev/demo

It's just not triggered by dnd like on https://node-projects.github.io/web-component-designer-demo/index.html, but there's a button / ad_group icon that triggers similar behaviour?
UPD: actually, in dockview demo, un-docking to floating window with dnd works if you hold Shift mod while moving the panel out.

[evonox]

@timadevelop

1. I tried now DockView and for instance when the TabStripBar is smaller than available space for Tabs, "ugly" browser scrollbar appears. There are a lot of subtle, at fist glance invisible things, I do not want to have in my library.
2. By floating windows @jogibear9988 meant that I can drag the panel and it will be floating inside the browser, not a new browser window.
3. I included animations, because it gives users better UX experience of using your product.
4. I support more window states than DockSpawnTS like maximization, minimization, etc. These states are certainly possible to turn off.
5. Apart of wcCabinDocker library I do not know any, that supports minimizing to collapsers.
6. @jogibear9988: As for the adoptNode in opening the panel to a browser popup-window I will have to make an option. I ran into scenarios with some diagramming libraries for which I need to use the classical approach like Golden Layout, that is using cloning. It will be there for handling edge cases, when adoptNode will not work.

[timadevelop]

2. By floating windows @jogibear9988 meant that I can drag the panel and it will be floating inside the browser, not a new browser window.

Exactly, floating groups triggered by Shift mod seem to work & cover this use case on dockview demo page.

1. I tried now DockView and for instance when the TabStripBar is smaller than available space for Tabs, "ugly" browser scrollbar appears. There are a lot of subtle, at fist glance invisible things, I do not want to have in my library.

afaiu the scrollbar is customizable. Do you mean that in your case it'd be more favorable to have "squished" tabs like on https://node-projects.github.io/web-component-designer-demo/index.html?

@evonox do you intend to use the new lib in some production / commercial / paid apps or is it a personal side project atm?

[jogibear9988]

@timadevelop is "not removeing elments from dom" possible in dockview?
This is for me the biggest needed feature. It means in dockspawn, only then x&y position and the width and height of the embeded child is changed, never it's position in the dom (only when you undock to a new browser window). This really matters if you have big dom trees

[PerBothner]

The dev branch of GoldenLayout does not (by default) remove elements from the DOM when they are moved. In earlier versions the content element hierarchy matches the layout hierarchy; that is no longer the case.

Note the dev branch by default uses the DOM drag-and-drag API, which allows you to move sub-windows between different top-level windows. Of course in that case content sub-windows have to be copied.

However, it is possible to use separate top-level "raw" windows for each sub-windows. In that case you don't need to copy any window content even when dragged into a different top-level window. Instead we just re-position each sub-window. This is not done directly by GoldenLayout, but it has the mechanisms to do so. DomTerm manages windows this way when using the Qt wrapper. (There is experiemental support for doing the same when using the Electon wrapper, and it looks like it should be possible when using the Tauri/Wry wrapper, though I have not looked into it.)

[mathuo]

@timadevelop is "not removeing elments from dom" possible in dockview? This is for me the biggest needed feature. It means in dockspawn, only then x&y position and the width and height of the embeded child is changed, never it's position in the dom (only when you undock to a new browser window). This really matters if you have big dom trees

Since dockview got a mention here I will add some details around the questions above raised.

For those who are interested: https://github.com/mathuo/dockview

Also, kudos to anybody developing a package related to layout management, it's a suprisingly complex thing to design.

Rendering (retaining DOM state)

Dockview supports both removing the panels content from the DOM when it is no longer visible and also keeping that content in the DOM.

The default behaviour is to remove the contents from the DOM since that's the most optimal solution but keeping the DOM alive for hidden panels is popluar since you will retain state specifc to the DOM such as scroll postions natively (and additonally if you are rendering iframes you need to keep that content in the DOM otherwise you run into all kinds of problems).

The mode you are using to render the panel can be dynamically switched out per panel and is persisted as layout state too.

There is some documentation on it here.

Floating Groups, Popout Windows and Maximized Groups

Floating groups as mentioned are supported and triggered by holding shift when moving a panel and panels can be "undocked" into new windows through the api. You can also maximize a particular group.

See Floating Groups
See Popout Groups
See Maximized Groups

Header Scrollbar

The scrollbar "issue" (I would prefer to call it "meh UX") when the group is too narrow is a little annoying and there is an open issue on this to have something a little better although I would also imagine you could use something like OverlayScrollbars here to get a nice non-native scrollbar.

Dependencies and Frameworks

dockview is and always will be zero dependency. The core package is written in plain TypeScript and can be used without any framework, although this still needs to be documented a little better. There are also packages for native support with both React and Vue, there is also demand for an Angular package which is planned. React is by far the most popular use-case currently.

Documentation

The documentation on dockview is fairly well covered and actually consumes quite a lot of the dev time as the package as grown in complexity ensuring that everything is well documented with examples.

You can view the documentation website here.

[jogibear9988]

Dockview supports both removing the panels content from the DOM when it is no longer visible and also keeping that content in the DOM.

The default behaviour is to remove the contents from the DOM since that's the most optimal solution but keeping the DOM alive for hidden panels is popluar since you will retain state specifc to the DOM such as scroll postions natively (and additonally if you are rendering iframes you need to keep that content in the DOM otherwise you run into all kinds of problems).

This is not the thing im talkin about here.

It's about if a elment when moved form one dock to another (or opened as dialog) is moved from one dom node or only repositioned. If you have huge DOM Trees (we have trees with 1000s of elments (visualization applications)) it only works, if the dom node stays in the same DOM elment and it is only repositioned

[jogibear9988]

Floating groups as mentioned are supported and triggered by holding shift when moving a panel and panels can be "undocked" into new windows through the api. You can also maximize a particular group.

Do you also support to undock to a new Window via adoptNode, or do you load the script and content in the new window?
Dockspawn-ts only does the first at the moment. (And I've added a hack so webcomponents adopted stylsheets are copied)

[evonox]

@timadevelop: Nope, I do not plan to use my library in my own commercial product. It will be free under MIT license and I will do maximum for commercial companies to trust this library and to use it in production-ready enviroments. But to reach the objective it will take some time.

[evonox]

@timadevelop As for the React/Vue/Angular Framework support I have a different perspective of the future for the Docker Library. It should be framework-agnostic library that should easily plug-in into micro-frontend frameworks like SingleSPA. Then each content of panel could be a different micro-frontend application with its own framework, VanillaJS or using WebComponents.

[jogibear9988]

@timadevelop As for the React/Vue/Angular Framework support I have a different perspective of the future for the Docker Library. It should be framework-agnostic library that should easily plug-in into micro-frontend frameworks like SingleSPA. Then each content of panel could be a different micro-frontend application with its own framework, VanillaJS or using WebComponents.

I think this should be possible with each of the other dock libs already. If you open the content in an iframe

[timadevelop]

It's about if a elment when moved form one dock to another (or opened as dialog) is moved from one dom node or only repositioned. If you have huge DOM Trees (we have trees with 1000s of elments (visualization applications)) it only works, if the dom node stays in the same DOM elment and it is only repositioned

@jogibear9988 pardon for my ignorance, but do you achieve this by absolute positioning "container" DOM elements that hold the content, which just happens to be a web component in the webcomponent designer example you shared above? Doesn't this cause problems with a11y and responsive layouts that run both on desktop and mobile platforms?

@jogibear9988 do you believe this whatwg/dom#1255 would discard the need for such shenanigans in your (and most) use cases?

@mathuo do you think this is possible and actually needed in dockview considering whatwg/dom#1255 ?

[jogibear9988]

@jogibear9988 pardon for my ignorance, but do you achieve this by absolute positioning "container" DOM elements that hold the content, which just happens to be a web component in the webcomponent designer example you shared above? Doesn't this cause problems with a11y and responsive layouts that run both on desktop and mobile platforms?

Don't know what sort of a11y issues you mean? DockSpawnTs Samples work on mobile and desktop. The children and also the container do not have to be webcomponents. Look at the DockSpawnTS IDE sample, there are no webcomponents.
And yes, the content div's are absolutely positioned ones. I added this support later, when I ported dockspawn it also moved the content around

@jogibear9988 do you believe this whatwg/dom#1255 would discard the need for such shenanigans in your (and most) use cases?

maybe this would solve it, but it for sure will take months (maybe years) untill such an API arrives

@mathuo do you think this is possible and actually needed in dockview considering whatwg/dom#1255 ?

[timadevelop]

Don't know what sort of a11y issues you mean?

afaik screen readers and the whole ARIA spec relies on DOM order. Some commercial apps have to be certified for a11y which includes a set of rules like providing high contrast settings, screen reader, etc.

And yes, the content div's are absolutely positioned ones.

Makes sense 👍

maybe this would solve it, but it for sure will take months (maybe years) untill such an API arrives

Yeah, probably years

[jogibear9988]

Don't know what sort of a11y issues you mean?

afaik screen readers and the whole ARIA spec relies on DOM order. Some commercial apps have to be certified for a11y which includes a set of rules like providing high contrast settings, screen reader, etc.

don't know if a docking UI could be usefully used in a screenreader

And yes, the content div's are absolutely positioned ones.

Makes sense 👍

maybe this would solve it, but it for sure will take months (maybe years) untill such an API arrives

Yeah, probably years

[mathuo]

In dockview when using the always rendered mode as you can see in the below gif those panels set to that render mode are positioned absolutly within the container with their DOM node position never changing. The elements are set to display: none when not visible.

In regards to opening panels in new windows you can view the code here which copies across the stylesheets before pushing the DOM node into the new document. It''s a fairly basic implemenation that doesn't do anything fancy as of right now, it does not make use of the adoptNode method.

[jogibear9988]

For me it looks, if you drag it out to a popup, it does change dom position or not? That is not the case in dock-spawn-ts

For the OpenInNewWindow, you need to do more, if you use webcomponents wich use adoptedStylesheets, see my code here: https://github.com/node-projects/dock-spawn-ts/blob/master/src/BrowserDialogHelper.ts

Also using your sample on a IPhone seems not to work for me. I could not drag around the views