All three of these have to be operated to be judged, so this page echoes what it received. Drag a window and it snaps to the other windows' edges and to the container, and draws the line it caught — a snap moves the window somewhere other than where you dragged it, which is an invention unless it is visible. Focus either scope below and press g: the same key does two different things. Press ctrl+x and the armed chord shows itself rather than silently swallowing your next keystroke.

windows that snap

drag by the title bar, or focus one and use the arrow keys. the guide line is the snap being honest about having moved the window. alt plus an arrow is the fine step and deliberately ignores the grid, because an override has to actually override

one key, two meanings

scope is resolved from the DOM: the innermost [data-ov-scope] ancestor of whatever has focus wins. that means the scope follows the USER rather than the application's idea of where the user is, and those two drift apart the moment anything unexpected is focusable

🔴 an armed chord is visible and cancellable. a prefix that silently swallows the next keystroke is a mode, and an invisible mode is the oldest interface failure there is. escape cancels, and the arm times out on its own. ⚠️ bindings never fire while focus is in a text field: a console that steals a key from a search box is worse than one with no shortcuts

the tab row, operable

the row was correct ARIA and correct look with no keyboard model at all: every tab a tab stop, arrows dead. now it is one stop for the whole row, arrows move and wrap, home and end jump, and selection follows focus. it enhances the existing markup rather than replacing it, because chrome is CSS in this kit and a custom element would mean the row only exists where JavaScript ran