Pane widths have to track the window

What it is

A tablet window is not a locked landscape rectangle. Split-screen, windowed stage modes, an external display, or a further fold all change usable width while the app is still open. Pane widths tracking the window means the two columns re-divide leftover space by ratio or by constraints, instead of remembering the pixel values from one landscape pass. A list pane locked at 320 points starves the detail as the window narrows; both panes locked in pixels leave a dead gap when the window grows. Simultaneity holds only while each pane stays in a readable band. If the ratio does not follow the window, one pane fails first. This entry is only about how width is shared while two panes remain. It is not about collapsing to one pane, and not about why two panes are useful.

Why it happens

Two panes share a horizontal budget that keeps moving. Each pane has a minimum: the list must fit identifying fields, the detail must fit body text or a form. On a resize, meet both floors first, then give leftover width to the pane that consumes it (usually detail). A fixed ratio looks fine in the middle of the range and then drives both panes through their floors at once. Fixed pixels refuse to donate space when the window grows. A user dragging the split divider is an in-window width jump; an app that computes pane width only at launch will clip type, wrap chaotically, or grow a horizontal scrollbar after the drag. Inner and cover displays on a foldable are not the same width; reusing cover-display pane sizes on the inner display produces one overfed column and one starved one.

Where it stops holding

If the user has deliberately dragged the divider, honor that rewrite for the rest of the session rather than snatching it back on the next rotation—but still enforce floors, so a pane cannot be dragged into unreadability. After a collapse to one pane there is no ratio to track. Read-only tools whose detail is a fixed canvas (a score, a layout preview) should keep the canvas undistorted and absorb change in the list pane or in margins, rather than kneading both columns. On a very wide window (an external display) unbounded detail width ruins measure; cap the text column and put leftover space into whitespace or a third pane instead of stretching forever.

Applying it

• Set a minimum width on each pane and distribute leftover space with flex weights. Do not hard-code pixels on both.
• Recompute on window width, split-divider movement, and fold-state changes—not only on first layout.
• If the user dragged the divider, remember that ratio for this session; after rotate or unfold, meet floors first, then apply the stored weights.
• Verify by dragging from full landscape to about one-third and back. Identifying fields must stay readable, detail must not scroll horizontally, and neither pane may collapse into an icon strip. Clipping or a dead band at any stop means the ratio is not tracking the window.

Related

• Within the group: K3.01.1 Two panes keep the list and the detail on screen together · K3.01.3 A narrow window collapses to one pane and still needs a way back
• Adjacent: K2.01 Window Management · K3.05 Split-screen and Multitasking · K3.03 Fold-state Transitions
• Search terms: pane width · split view ratio · liquid layout