Spanned layout

A dual-screen device gives an app two choices: sit on one screen, or span both. Spanned is the interesting state, because the window the app is handed is not a rectangle it can trust. Running down the middle is a seam, which on a two-panel device is a physical gap and on a single folding panel is a crease, and either way it is a strip where pixels are either not shown or not comfortably read, and where a finger cannot reliably press. Microsoft’s dual-screen documentation calls the occluded strip the display mask, and calls the app’s condition spanning.

There are only three things a spanned layout can do about the seam, and two of them are fine. The unaware layout treats the window as one wide rectangle, which puts a line of text and usually a control straight across the mask: half a sentence and half a button vanish into the hinge. The avoiding layout keeps its single-pane arrangement but reflows so nothing important lands on the strip. The splitting layout goes further and treats the seam as a gift, using it as the gutter of a two-pane arrangement, list on one screen and detail on the other, master and canvas, board and inspector. Splitting is the outcome worth designing for, because the hardware boundary and the content boundary then agree, and the seam stops being damage.

The nearest term is device posture, and the pair divides cleanly: posture is the shape the hinge is currently in, which is hardware, while spanning is what the layout does about it, which is yours. A device can be flat and spanned, or in book posture and spanned, and the arrangement decision is the same either way. The other neighbours are the family the seam belongs to. A safe area is a region kept clear of system furniture, and a display cutout is a hole in one screen; a seam is the same class of problem, an area of the window that content must respect, arriving from a different direction.

On the web this is still thin ice. The relevant features are the viewport-segments environment variables and the horizontal-viewport-segments and vertical-viewport-segments media queries, which report the window as a set of segments with the gap between them, and they remain narrow in support and easy to get wrong when a device folds while your media query cached. Two habits carry most of the value with none of the risk. Give any two-pane layout a gutter that is generous enough to be a seam if it ever has to be one, and never centre a single primary control in a window whose width you did not choose, since the middle of the screen is exactly where the hardware boundary lives.