Window splitter

Problem Context

• Two or more adjacent panes must remain visible in one workspace, such as list and reading pane, editor and preview, navigation and content, form and activity, or table and inspector.
• Users have legitimate reasons to allocate more space to one pane at different moments.
• Pane contents have state such as selected rows, scroll positions, text entry, zoom, filters, or preview focus that must survive resizing.
• The product can define minimum usable sizes, collapse behavior, keyboard steps, and narrow-screen alternatives.

Selection Rules

• Choose window splitter when adjacent panes are both part of the same durable workspace and users need control over their relative sizes.
• Use a fixed details panel when the panel's job is selected-object inspection and user-controlled pane ratios are unnecessary.
• Use a drawer when the surface is temporary, edge-aligned, and should close after supplemental detail or light action.
• Use side navigation when the side region contains destination hierarchy rather than resizable content.
• Use tabs, accordion, or full-page routes when the viewport cannot support readable side-by-side panes.
• Do not use a splitter for a purely decorative divider.
• Do not use a splitter when one pane can be safely hidden without restore, orientation, value, or state preservation.
• Do not allow either pane to resize below its minimum useful content width or height.
• Define whether collapse happens by Enter, double-click, a button, or a dedicated command, and provide restore behavior.
• When multiple splitters exist, label each one by the panes it separates.

Required States

• Default split state with two labelled panes and a visible splitter position.
• Keyboard-focused splitter state with accessible name, orientation, value, min, and max.
• Pointer drag or step resize state with live pane size update.
• Arrow-key resize state with predictable increments.
• Home and End or min and max boundary state.
• Collapsed pane state with a clear restore affordance.
• Restored pane state preserving selection, scroll, and input state.
• Minimum and maximum boundary feedback state.
• Responsive narrow-screen state with stacking, route, or collapsed pane alternative.
• Multiple splitter state where each separator has a distinct name and target panes.

Interaction Contract

• The splitter separates two named panes and communicates which pane size its value represents.
• Pointer dragging changes pane size within defined min and max limits and does not select text or lose pane state.
• Keyboard focus can land on the splitter when it is moveable.
• Arrow keys resize the panes by an intentional step; larger modified steps may be supported.
• Home and End move to minimum or maximum where those shortcuts are implemented.
• Enter toggles collapse or restore only when the design explicitly supports that behavior.
• The splitter updates aria-valuenow or equivalent value text as the pane size changes.
• Resize, collapse, restore, and responsive changes preserve active selection, scroll, input, and focus unless the user explicitly navigates away.
• When a pane reaches a boundary, the interface communicates the limit without moving focus away from the splitter.

Implementation Checklist

• Name both panes and define which pane the splitter value measures.
• Choose vertical or horizontal orientation and provide matching visual affordance.
• Set initial size, minimum size, maximum size, step size, and collapse threshold.
• Use role separator with aria-valuenow, aria-valuemin, aria-valuemax, orientation, and an accessible name when implementing an ARIA splitter.
• Implement pointer drag, keyboard arrow steps, boundary feedback, collapse, restore, and responsive fallback deliberately.
• Preserve pane state including selected item, scroll position, text entry, preview zoom, and focus after resize.
• Avoid hidden tiny panes by enforcing minimum useful sizes and exposing restore.
• Test keyboard, pointer, touch, screen reader output, zoom, high contrast, localization, nested scroll panes, and narrow breakpoints.

Common Generated-UI Mistakes

• Using a static separator line and calling it a splitter.
• Making resizing pointer-only with no keyboard or assistive-technology value.
• Letting panes collapse to unusable slivers without restore.
• Using a splitter when a drawer, details panel, or responsive layout would better match the task.
• Forgetting min and max limits, causing text clipping and broken controls.
• Resetting form input, selection, or scroll position after resize.
• Adding several unlabeled splitters to one workspace.
• Treating the splitter as the pane content pattern instead of separately designing the table, preview, editor, or navigation pane.

Critique Questions

• Which two panes does the splitter separate, and why must both stay visible?
• Which pane does the current value measure, and what are its minimum and maximum useful sizes?
• Can pointer, keyboard, and assistive-technology users resize, collapse, and restore the panes?
• What happens to selection, scroll, focus, and input while resizing?
• What is the narrow-screen alternative when panes cannot remain side by side?
• Would a fixed details panel, drawer, side navigation, tabs, or full-page route be clearer?