Rich, web-friendly editor UI framework for SolidJS + TypeScript

Fork 0

solid-stage docs editor-panel-docking-patterns.md

51 kB · 385 lines

Markdown

at main

mochi.nuffle.me · feat: consumer audit fixes, collapsed panel tabs, full layout reset · 1w ago

cbd4720a

Side-panel presence and docking in editors #

You're reading this because the overlay-mode collapse bar permanently covers part of the stage, and we have to choose between (a) reserving a margin for it, (b) a small floating edge tab, (c) a fixed application rail, and (d) panels that can be dragged and docked to either side. The June report asked what a rail click should do. This one asks how a panel stays reachable when it's collapsed, and where it's allowed to live.

Outcome (2026-11-04): we built tab and none as recommended, with one change: strip now reserves its column in overlay mode instead of keeping today's bar over the center, so it's the reserved strip from option (a). We also went against the advice below and made the tab draggable, under the same lock as sections. The rail and docking stay parked, in feature-ideas.md.

TL;DR and recommendation #

Build a fixed small tab, plus a "no affordance" option, for collapsed overlay panels. That's (b) without the drag. Leave (c) and (d) parked until a consumer asks for them.

The closest prior art is Blender, not VS Code. Blender can let its Sidebar overlap the 3D viewport, and a hidden region "leaves a little arrow sign" you click to bring it back (Region Overlap, Regions, Blender 5.2 LTS). That is our use case with a shipped answer.
VS Code doesn't do what overlay mode does. Its side bars take layout space, and the request to auto-hide them has been open since 2016 with 597 upvotes. Treat VS Code as the model for rails and for moving views. For overlays, look at JetBrains, Visual Studio and Blender.
Our current bar is the outlier. Every overlay-style product we could source either reserves a strip for the collapsed affordance (JetBrains, Visual Studio, 3ds Max, FlexLayout, as far as their docs show) or shrinks it to something tiny (Blender, Ant). We found nothing that lays a full-height bar over content.
(a) is more respectable than you think, and still not my first pick. A reserved strip keeps overlay's main benefit, because opening and collapsing still never resize the center. It costs 20px per side at the normal tier. But an empty reserved strip is the worst version of that idea: if we're going to pay for the column, it should hold icons, and that's (c).
Dragging the tab along the edge is the part to cut. We found it only in phone OS shells and a browser extension, and in none of the editors we surveyed. Those shells have no app chrome to host a button. We do. A configurable position solves the collision problem at a fraction of the cost.
(c) and (d) are separable, and (d) is three different features. A side-flip setting is cheap. Dragging a whole panel to a side is expensive. A tree of arbitrary splits is a different product. The market-leading library sells auto-hide and dock-to-edge as paid features, which says something about where the hard work sits.
You're not being idealistic about the direction, only the order. At the commits I checked, no consumer sets leftPanelMode or rightPanelMode yet. So the rail and docking have no pull, and overlay itself has none in consumer code yet.

What are these patterns called? #

There's no single standard vocabulary. A few terms are understood everywhere, and many are one product's branding. For our docs and API, I'd use the terms marked "Common".

Term	Meaning	Status	Source
Overlay vs push / inline / inset	Panel covers the content, or displaces it	Common. Exact words vary	Fluent's `OverlayDrawer` / `InlineDrawer`, FlexLayout's "split/overlay"
Dock	Attach a panel to a frame position rather than float it	Common	Visual Studio
Float / tear-off / popout	Detach within the window, or into a separate OS window	Float is common. Popout is mostly web libraries	Dockview
Auto-hide / pinned / unpinned	Panel slides away when it loses focus, and a pin keeps it open	Common. Lots of apps use it	Visual Studio, JetBrains
Peek	Temporarily reveal an auto-hidden panel as an overlay	Understood, not formal	Dockview's auto-hide docs
Rail / navigation rail	Permanent narrow icon strip for switching destinations	Common. Material's formal term	M3 navigation rail
Drawer	Panel that slides in from an edge	Common on web and mobile, and Unreal uses it too	MUI, Unreal
Temporary / persistent / mini variant / permanent	Drawer behaviors	MUI's names, widely recognized	MUI
Offcanvas vs icon collapse	Collapse to nothing, or collapse to an icon strip	shadcn's names, a useful distinction	shadcn sidebar
Workspace / layout preset	Saved arrangement of panels	Common in creative and IDE tools	Godot, Resolve
Activity Bar, Primary / Secondary Side Bar	VS Code's rail and panels	Product-specific, widely known	VS Code
Tool window bar ("stripe" informally)	JetBrains' rail. The current docs say "bar"	Product-specific	JetBrains
Guide diamond ("compass" informally)	The drop-target cross shown during a drag	Visual Studio's term	Visual Studio
Edge handle / edge tab / zero-width trigger	Small grab tab on an edge	No standard name. "Handle" is Samsung's, "special trigger" is Ant's	Samsung, Ant
Icon dock / collapse to icons	Panels shrunk into an icon column	Adobe's terms	Photoshop

So the answer to the literal question is: VS Code's rail is an "activity bar" or "navigation rail", overlay mode is "overlay" or "auto-hide", and the panel-dragging feature is "docking". What we call the edge bar has no established name, because nobody else really ships it.

How do other editors keep a collapsed panel reachable? #

Evidence key: Docs means I read it in current vendor docs. Thread means a user report on a forum or issue tracker. Silent means the docs I read don't say, and I'm not claiming anything.

Product (version where known)	What stays on screen when collapsed	Overlays without resizing the center?	Moving panels; several per side	Evidence
Blender 5.2 LTS	A small arrow	Yes, Region Overlap	Regions are fixed. Areas split.	Docs
JetBrains 2026.2	Tool window bar with icons, which can itself be hidden	Yes for Undock, which "covers part of the editor". Dock Unpinned shows only when active, but the docs don't say whether it reflows.	Drag icons between bars. Drop below a separator to split.	Modes, bars
Visual Studio (docs updated Oct 2026)	Named tabs on the IDE edge	Yes in practice: auto-hide "slides". The doc doesn't discuss reflow, but Dockview describes the pattern as non-reflowing.	Drag with guide diamond, anywhere in the frame	Docs
VS Code (Nov 2026)	Activity Bar. It can sit at the top or bottom, or be hidden.	No. The layout docs describe no overlay, and #3742 is still open.	Primary moves by setting or context menu, not by dragging. Secondary is "always positioned opposite". Views drag between them.	Docs
Unreal	Drawer buttons on the bottom bar, sidebar tabs	Yes. Drawers are temporary and minimize on focus loss.	Dock in Layout makes a persistent instance. Tabs dock anywhere.	Docs, sidebar tabs from thread
Unity 6.6	Windows: silent. Scene overlays collapse to a small control when docked.	Scene overlays yes, and they're inside the 3D view	Tabs drag with an outline preview. Overlays have blue drop zones.	Windows, overlays
Godot (stable docs)	Silent	Silent	A menu moves a dock, or makes it floating. Saved layouts.	Docs
Photoshop (Feb 2026)	Icon dock, with or without labels	Silent on whether expanding reflows. Auto-collapse exists in "some products".	Drag icons between docks, or out to float	Docs
Figma UI3 (Oct 2024 post)	Minimize UI collapses panels. Users report it collapses both sides together.	Only under Minimize UI, Slides grid view and FigJam. Default panels went back to fixed.	Not movable, as far as I found	Figma blog
Maya	Tabs. Click the current tab to collapse the pane, any tab to restore it.	Silent	Drag out to float, or dock	Docs
3ds Max	Thin labeled strip that opens on hover	The doc says "temporarily". Silent on reflow.	Command panel docks left or right only	Docs
DaVinci Resolve 21.1	Toolbar buttons and a Workspace menu	Silent	No general undock. Presets instead.	Third-party guide
Excalidraw	A trigger button you place	Yes by default. Docking is opt-in, and undocked closes on outside click.	Dock toggle only	Docs
tldraw	Style panel floats top-right on desktop, and moves into a popover on mobile	Yes	No	Docs

Miro and Photopea: I couldn't source anything useful, so I make no claim.

Four patterns stand out:

A persistent strip with labels or icons is the most common answer in the tools built for long sessions. An overlay on top of that strip is a well-trodden combination.
The move-to-side action is often not a drag on the whole panel. VS Code uses a setting or context menu for the side bar. Godot uses a menu. JetBrains drags the rail icon. Only the classic docking systems drag the panel itself.
Having several panels per side is rarer than it seems. VS Code keeps Primary and Secondary on opposite sides and stacks views inside them. JetBrains supports a top and bottom split. Free arrangement belongs to Visual Studio, Unity and Unreal.
Small tabs do exist in serious editors. Blender's arrow is the good example, and it's in a 3D tool. Ant Design's zero-width trigger is the web equivalent, appearing when collapsedWidth is 0.

Who has a tab you can drag along the edge? #

No surveyed desktop or web editor documents one. That's an absence in what I read, not proof that none exists. The examples I did find:

Example	Behavior	How it's regarded
Samsung Edge panels	Handle drags up, down, or to the other side. There's a lock switch. Size and transparency are adjustable.	The closest match. The existence of a lock switch implies accidental moves happen (my inference). I found how-to guides for turning it off, but no quality data.
iOS AssistiveTouch	Button drags to "any edge of the screen, where it stays"	Accessibility feature. Free-floating, not a panel handle.
PixieBrix extension	Experimental floating button with a drag handle and a hide button	Extensions inject into pages they don't own, so they need a way to dodge content.
Microsoft Edge sidebar	Always on / Auto hidden / Off. Not a draggable tab.	Third-party report from 2024.

Windows Copilot and Widgets: I found nothing that documents an edge-draggable tab, so I make no claim.

My read (inference): this pattern exists where the UI floats over content it doesn't control, and so the user has to dodge the collision by hand. A library whose consumers control their own layout can solve the collision at authoring time.

What do docking libraries tell us about the cost? #

Metrics are from GitHub, npm and Bundlephobia on 2026-11-04. Gzip is the Bundlephobia figure, shown only where I checked it.

Library	Stack, licence	Activity	Size	Touch	Collapse / overlay
Dockview	Vanilla, React, Vue, Angular. No Solid. MIT core, proprietary enterprise.	3.5k stars, v8.8.3 Oct 2026, ~868k weekly (`dockview-core`)	90 KB, zero deps	Pointer backend, closed as done Sept 2026. An older mobile issue is still open.	Edge groups collapse to a 35px strip. Auto-hide and dock-to-edge are enterprise.
FlexLayout	React, MIT	1.4k stars, v0.11.1 Sept 2026, ~145k weekly	53 KB	README claims iPad and Android. Divider dragging reported flaky in 2024.	Borders either split or overlay. The closest match to our modes.
Golden Layout	Vanilla, MIT	6.7k stars, last release Sept 2022, ~50k weekly	30 KB	Claimed. A touch-drag bug is closed, and I didn't confirm how it was fixed.	Not in what I read
rc-dock	React, Apache-2.0	815 stars, ~27k weekly	Not checked, six runtime deps	README doesn't claim it	Float, maximize
Dock Spawn TS	Vanilla, MIT	148 stars, ~300 weekly, Oct 2026	Not checked	README claims iPad, iPhone and Android	Pin-to-collapse tool panels
Lumino	Vanilla, used by JupyterLab	764 stars, Oct 2026	Not checked	Touch request open since 2020	Not reviewed
Theia	Depends on Lumino	21.7k stars, active	Full IDE framework	Touch request open since 2018	Not reviewed
Dear ImGui docking	Native C++, MIT	Active	n/a	Not reviewed	Lives on a branch. The author plans a rewrite.
QDockWidget	Qt	Maintained by Qt	n/a	Not reviewed	Closable, movable, floatable. Its page mentions no auto-hide.
Qt ADS	Qt add-on, LGPL	2.5k stars, v5.1.1 Aug 2026	n/a	Not reviewed	Auto-hide tabs in four sidebars, with drag to sidebar
AvalonDock	WPF, MS-PL	1.8k stars, v5.0.1 Oct 2026	n/a	Not reviewed	Auto-hide manager, built-in sidebar

The hard parts, as far as public evidence shows:

Touch. It's where the mature libraries lag: Lumino's and Theia's requests have sat open for years, and Dockview only closed its drag request in September 2026. We've already done this work for sections, which is a real advantage.
System gestures stealing drags. Lumino has an open bug where a touch drag taken over by a system gesture ends in pointercancel and never releases.
Keeping content alive while it moves. Dockview's rendering docs spell out the trade-off: unmounting loses scroll position and measurements, keeping things mounted leaves work running, and re-parenting an iframe reloads it. Its tracker has fresh bugs in exactly this area (moving into a collapsed edge group, retained DOM).
The overlay and edge modes themselves. Dockview's auto-hide and dock-to-edge sit behind its commercial licence, and the public request for auto-hide is still open. Qt's add-on exists largely to provide what QDockWidget doesn't (my inference).

WebGL. I found no library documentation about a WebGL center specifically. That's a gap. We do have an architectural head start: the center stays put in all of (a) through (d), whereas in the general-purpose libraries the viewport would typically be one more movable panel (inference). Moving panels around a stationary canvas avoids most of this category of problem.

Should we adopt one instead of building? No. Dockview's model is tabbed groups in a grid, and ours is sections in docks. Adopting it means replacing the model consumers already use and writing a Solid binding, plus paying for the feature most relevant here. This is my judgment, not a sourced finding.

Design systems point the same way:

Material 3: the collapsed rail "should not be hidden", and compact windows "should always use a navigation bar" rather than a rail. The expanded rail's modal form "overlaps the body content" and suits "information dense layouts where space is limited". In immersive experiences it may be hidden entirely and opened from a menu icon, which supports our "no affordance" option.
shadcn: offcanvas, icon and none, with a separate trigger and a Sheet on mobile. This is the closest web precedent for separating the panel from its toggle.
Fluent: overlay is a per-case decision based on whether interacting with the background helps.
MUI: temporary, persistent and mini variants.
Carbon: the left panel page describes a fixed panel and doesn't discuss overlay.

What does the evidence say about each option? #

Option	Solves the rest-state occlusion?	Keeps "no resize on open"?	Phone	Cost (my estimate)	Verdict
(a) Reserved strip	Fully	Yes	Poor: about 10% of a 390px screen for two strips	Small	Honest fallback
(b1) Fixed tab	Mostly	Yes	Fine, if tap-only	Small	Build now
(b2) Draggable tab	Mostly	Yes	Risky near the edge	Small to medium on top of b1	Defer, probably never
"None" + app toggle	Fully	Yes	Good	Small, shares b1's work	Build now
(c) Rail	Fully	Yes, after one resize at mount	Replace with a bar	Medium	Wait for pull
(d1) Side flip by setting	Unrelated	Unrelated	Fine	Small to medium	Wait for pull, cheap when it comes
(d2) Drag to re-side	Unrelated	Unrelated	Hard	Large	Only after (c)
(d3) Split tree, compass	Unrelated	Unrelated	Very hard	Very large	Avoid

(a) Reserved margin #

For. It's the mainstream arrangement in long-session tools: strip reserved, panel overlaid. Your objection is half right. Overlay's WebGL benefit survives, because the center resizes once at mount and never on open or collapse. Only the area benefit shrinks: at the normal tier a strip is 20px, so two strips take about 2% of a 1920px window. Mouse users also keep a full-height target flush with the window edge, which Fitts's law treats as effectively infinite in one direction.

Against. About 10% of a 390px phone. No information in the strip. A permanent reservation is exactly what overlay mode was added to avoid.

Fit. Very easy: the overlay track goes from 0px to --stage-strip-width while collapsed, and inset mode already does this. One catch: the track would need to stay at strip width whether the panel is open or collapsed, or the center resizes after all.

(b) Small edge tab #

For. Blender and Ant are direct precedents. It removes the sliver over the toolbars and most of the area loss.

Against.

It still occludes. Less area, but a tab twice the bar's width reaches further into the stage. At the normal tier that's 40px deep. I'd make it narrower for mouse (see the sizes below). A tab placed at the vertical center is likely to avoid topSub and bottomSub (inference, and worth checking in real consumers).
Discoverability. NN/g's study of hidden navigation (2016, 179 participants) found discoverability dropped more than 20% and desktop tasks took at least 39% longer. That's about content sites, so it applies only loosely to a power tool whose users learn the layout quickly. But it's a reason not to make none the default.
Gaps ruin edge targets. An Unreal user calls a small gap between the sidebar and the screen edge a "pixel hunt". The tab must be flush with the window edge.

Target sizes.

Apple asks for a 44x44pt hit region.
Material suggests 48x48dp, noting the target can exceed the visual.
WCAG's minimum is 24x24 CSS px, with a spacing exception.

So a modest visible tab can carry a larger hit region on pointer: coarse. Our strip at the normal and small tiers is under 24px wide, so it depends on that spacing exception (my reading, not an audit).

Why not the drag?

Precedent is weak, as shown above.
A tap and a drag on a tiny target have to be told apart. We have that threshold logic in the edge variant, but on touch the two are easier to confuse.
It adds state: a persisted position, clamping on resize, collision with other UI. It also needs a non-drag way to reposition, since WCAG 2.5.7 asks for a single-pointer alternative to dragging.
It starts in the worst place on an iPhone. See the next section.

If collisions turn up, a --stage-panel-tab-offset-style setting fixes them at authoring time, and it's the same value a later drag would write. So we lose nothing by waiting.

Touch and edge gestures (applies to anything on the edge) #

Don't add swipe-to-open. WebKit closed the request to let pages handle edge swipes first as WONTFIX, on the grounds that back-swipe should be consistent. Apple's guidance is to avoid conflicting with gestures that access system UI. MUI turns off swipe discovery on iOS for this reason. Android needs explicit exclusion rects, which a web page can't set (my inference).
A workaround exists, but don't lean on it. A 2020 post blocks navigation gestures with preventDefault on touchstart within 20px of the edge. I didn't verify it on current iOS, and it would need testing on the real iPhone.
Tap is safe. Vertical drag near the edge is unverified. A drag starting in that zone may be cancelled by the system, as in the Lumino bug. This is an inference to test before ever shipping (b2).
Edges don't help on touch. NN/g reports that the screen-edge advantage "offers no advantage for touchscreens" and edge targets may even be slower.

(c) Rail #

For. The most established answer: VS Code, JetBrains, Photoshop's icon dock, and Material's formal component. It's informative, since it shows what's available. Combined with overlay, the center never resizes when panels open, which is a clean pairing. The June report already worked out the router model and recommends labels over icon-only.

Against.

It costs a permanent 44px or more per side once buttons are big enough. That's about 11% of a phone per side, and Material says not to use a rail on compact windows at all. So we'd need a second form for phones, which is real extra design.
One-panel apps get a rail with one icon, which is a poor trade against a tab.
It needs an API for views that doesn't exist, and today's consumers author leftPanel as plain JSX.

A correction to the June report. It cited vscode#260437 as pressure to keep rail icons visible. That issue was closed as not planned in October 2025 by a bot, for lack of votes. It's still a fair statement of the request, but weaker evidence than that report implied. Material's "should not be hidden" is the better citation.

"Multiple panels per side" is two features. One at a time via the router is what VS Code does and is cheap. Two visible at once with a divider is what JetBrains does and needs a splitter and more state. Today's stacked Sections and accordion docks already cover much of the need for the second one (my judgment).

(d) Dockable to either side #

Sections can already move between docks with an insertion line, so users can already rearrange the content. What (d) adds is smaller than it sounds: moving the whole panel at once. The existing limit is that "dragging the static side panels themselves" isn't built.

(d1) Side flip by setting. This is VS Code's workbench.sideBar.location. It needs no drag, no indicator and no new interaction. The work is that chevrons, cover variables, persist keys and overlay positioning must follow a logical side.
(d2) Drag to re-side. The cheaper form is JetBrains' icon drag between bars, which depends on (c). Rails give a small set of drop targets, and the existing insertion line can serve as the indicator. Panel-header dragging without a rail has no drop target when the other side is empty, so we'd need Unity-style or dock-to-edge-style zones that appear during a drag, as Dockview's enterprise feature does.
(d3) Split tree with a guide diamond. The diamond exists because a drop could mean any of many positions in a tree. We have no tree. Without one, a compass solves a problem we don't have (inference).

Failure modes to expect from (d2) and up:

Accidental rearrangement is real. 3ds Max tells users who float the panel by accident to turn on Lock UI Layout. We have locked for sections, and it would have to cover panels too.
Empty sides. What does a side with no panels look like, and how do you drop onto it?
Persistence. Saved layouts need a version bump and migration. Consumers' HUDs anchored to --stage-panel-cover-left may now be under the wrong panel.
Remounts. Sections remount when they change docks, so a whole-panel move remounts every section in it, including any heavy ones (inference from the render thunk rule).
Nested stages. Embedded stages multiply the possible targets.
Phones. On a phone there's barely a "side" to move to, so this feature mostly doesn't apply there.

Is overlay itself a good long-term default? A caution #

Figma's experience is the strongest evidence here. It shipped floating panels over the canvas in its UI3 beta, then went back to fixed panels: they cramped the canvas, content "peeked" distractingly from behind them, and "the nail in the coffin was learning that they slowed people down". Community complaints included wasted space and overlap. Floating did survive in Minimize UI and in FigJam.

So: keep inset as the default, as it is today, and treat overlay as the mode for canvas-first or low-edit sessions. A dense property editor that's always open may be better off inset, and that's worth saying in the docs.

Auto-dismiss is divisive, so don't add it by default. VS Code users want overlay with auto-hide, while Unreal users say auto-hide "messes me up so often" and call Dock in Layout a workaround. Today's "tapping outside doesn't close it" is the safe choice. One caveat is that WCAG's focus-not-obscured guidance treats persistent non-modal overlays as a risk for covering focused items, so keyboard users need a clear way to dismiss the panel. I didn't audit our current behavior against it.

What should we do, and in what order? #

Do now: collapsed affordance for overlay panels #

Removes the immediate complaint. No consumer change required, because the default stays as it is.

// Sketch, not final naming. Applies to the collapsed state of an overlay panel.
leftCollapsedAffordance?: 'strip' | 'tab' | 'none'; // default 'strip'
rightCollapsedAffordance?: 'strip' | 'tab' | 'none';

strip: today's behavior.
tab: a small button flush with the window edge. Vertically centered by default, with a CSS variable for its offset. Visibly narrow, with a 44px-minimum hit region on pointer: coarse. Tap or click only, no hover and no swipe.
none: nothing on screen. The app toggles through the existing controlled props (leftCollapsed, onLeftToggle) from a button in topToolbars, which the panel never covers. Docs should say plainly that the app must provide a way back.
Cover variables: --stage-panel-cover-* should read 0px for tab and none while collapsed, so HUDs get the space back. Deriving that value from one accessor is cleaner than a parallel calculation.
Don't bind a keyboard shortcut in the library. VS Code and shadcn use Ctrl/Cmd+B, but in a library that's the app's decision, and the controlled props already make it easy.
Test on the real iPhone, in both portrait and landscape, with the tab near the safe areas.
Keep strip for mouse-first apps. Fitts's law favors it, and it's not wrong in inset mode, where it already takes its own column.

The width clamp of [140px, 40% of the stage] gives about 156px on a 390px phone, which looks tight for dense settings. tldraw uses a popover on mobile and shadcn a Sheet. That's a separate question worth raising, and I'd wait for a real phone complaint before acting on it.

Next, only if a real need appears #

Step	Build it when	What it reuses
Tab offset per app	Comes with the first step	CSS variable
Reserved strip (a)	Two consumers say the tab still collides	Inset mode's track logic
Side flip (d1)	A consumer or user group wants panels on the opposite side	Existing panels, a logical-side concept
Rail (c)	A consumer has 3+ mutually exclusive views on one side, and `Section` collapse and accordions aren't enough. Per `feature-ideas.md`, a second consumer should want it.	June report's router shape, `createPersistedToggle`, `TabMenu` patterns
Icon drag between rails (d2)	After (c) ships, and users ask to rearrange beyond moving sections	Pointer drag, insertion line, `dockHitTest`, the `locked` flag

How these depend on each other:

So yes, (c) and (d) are separable, but not in the obvious direction. (d1) needs nothing. (d2) is far cheaper after (c). (c) needs no part of (d).

What consumers do today #

At the local checkouts I read (dsts-viewer bb560b7, osrs-engine-study 1b28621, world-sim-assets e37c515), only the solid-stage playground and tests set leftPanelMode or rightPanelMode. dsts-viewer uses edge toggles. osrs-engine-study uses DockZones with the ids left and right only. That was a targeted search for these props and dock ids, not a read of each app, so it shows no sign of demand for more docks rather than proving there's none. These checkouts may lag behind work in progress, so check with the consumers before relying on this. I'd take it as a reason to build the small step, and as a clear signal to hold the large ones.

What not to do #

Don't wrap Dockview or similar. Wrong model, and the relevant features are paid.
Don't build the split tree or the guide diamond. The repo's rule against hypothetical needs applies directly, and sections and floating panels already cover flexible arrangement.
Don't add swipe-to-open, for the reasons above.
Don't make the panel open on hover by default. 3ds Max and browser sidebars do it, and it doesn't exist on touch, which makes it a second code path. Users do ask for it, so it could become an opt-in later.
Don't default to none. A hidden panel with no affordance is the discoverability trap.
Don't add a phone rail. Follow Material: use a bar or toolbar buttons on compact widths.

Sources #

Local: docs/editor-side-navigation-patterns.md, docs/layout.md, docs/dnd.md, docs/architecture.md, docs/feature-ideas.md, packages/solid-stage/src/theme/tokens.css, and the consumer repos named above.

Editors (vendor docs):

Editors (secondary and community):

DaVinci Resolve workspace presets, third-party guide
VS Code issues #3742, #248900, #178375, #193267, #260437
Unreal forums: Docking to Sidebar, Disable Content Browser Auto Hide, Keep Content Tray Open
Figma forum: Independent panel collapsing, Fixed panels are back

Edge handles:

Docking libraries:

Dockview: site, repo, licence, rendering, edge groups, auto-hide, dock to edge, issues #696, #930, #1283, #1596, #1738
FlexLayout: repo, borders demo, #432
Golden Layout: repo, site, #635
rc-dock, Dock Spawn TS
Lumino: repo, #77, #847
Theia: repo, @theia/core package.json, #3557
Dear ImGui: Docking, QDockWidget, Qt ADS, AvalonDock
Sizes: Bundlephobia for dockview-core, flexlayout-react, golden-layout. Weekly downloads came from the npm registry API.

Design systems:

Usability, accessibility and platform:

NN/g: Fitts's Law, Hamburger Menus and Hidden Navigation
WCAG 2.2: Target Size (Minimum), Dragging Movements, Focus Not Obscured
Apple HIG: Buttons, Gestures
WebKit bug 149015
PQINA: Blocking navigation gestures on iOS
Android: Gesture navigation

Fallbacks. docs.blender.org and helpx.adobe.com returned 403 to the default fetcher and were read through a browser-impersonating client. m3.material.io, Apple's HIG and the FlexLayout demo are JavaScript-rendered and were read through a headless browser. GitHub content came from the gh API, so GitHub links in this report are the web equivalents of what I read.

Further research #

Open questions

Does a flush tab behave on a real iPhone? Test tap reliability near the safe areas, and whether a vertical drag from the edge zone gets cancelled. This decides whether (b2) is even viable.
Where do consumers actually put HUDs? My vertical-center default is a guess until it's checked against dsts-viewer and osrs-engine-study layouts.
Should an overlay panel become a modal sheet on phones? tldraw and shadcn both change form on mobile, and the current width clamp looks tight. This is outside the question asked, but it's adjacent.
Does anyone plan to use overlay mode? No consumer does at the commits I checked, so it's worth confirming before investing further.

Weakly sourced claims

Unreal's sidebar tabs rest on forum threads and not on Epic docs. Content Drawer behavior is from Epic docs.
Figma's Minimize UI collapsing both sides comes from user posts. The Figma blog describes the feature but not that detail.
DaVinci Resolve comes from a third-party guide citing the 21.1 manual. Mirror pages of the manual that I tried returned 404.
Edge's "Auto hidden" mode comes from one 2024 tech-news article.
The iOS preventDefault workaround is from 2020, and I couldn't confirm it on current iOS.
The NN/g hidden-navigation numbers are from content sites in 2016. Applying them to expert tools is my extrapolation.
Cost estimates throughout are my judgment from reading our docs and file sizes. They aren't measured.

Inaccessible or empty

Lean Library's floating button help: redirects to a sign-in page in a headless browser. Search snippets suggested a corner-position setting, which I left out as unverified.
Orion's sidebar-hover thread: the page failed to load usable content, so I didn't use it for Arc or Zen hover behavior.
Samsung community thread on opening Edge panels with a case: only the title was readable.
SAP's mirror of Material drawer guidance: 404. As a result I didn't verify a search snippet claiming Material 3 Expressive deprecates the navigation drawer.
Photopea's learning index: nothing on side panels. Miro: nothing found. Both are left out of the survey.

Gaps in the source material

I found no controlled study comparing edge tabs, rails and strips for property-heavy editors. Everything here is vendor practice, user complaints and adjacent research.
I found no quality data on draggable edge handles. Samsung's feature has settings docs and how-to guides, not usability findings.
I found no docking library documentation about a WebGL center, including the effect of moving a <canvas> between parents. It doesn't affect the recommendation, since the center stays still, but it would matter if the viewport ever became a movable panel.
Docs often don't say whether a panel reflows the content. JetBrains' Dock Unpinned, Photoshop's expanded icons and 3ds Max's hover strip all fall here. Hands-on testing would settle it.
Dockview's public auto-hide request remains open even though the enterprise docs describe the feature. I didn't determine whether anything is planned for the MIT core.