The file focus band, photographed
Agent Manager · branch style/files-focus-name-band (77f50fc, off integration/all-14-plus-feedback) · every picture is the real Files pane in a browser, on that branch's stylesheet · 11 Sep 2026
What changed. The keyboard focus indicator is a band behind the file name: square, in the accent, 34% over whatever is underneath it. It replaces the neutral full-row band, which replaced the 2px outline.
How these were taken. The real FilesPane, the branch's real styles.css, mounted in Chromium against a fixture file list. Every focused row was reached by pressing Tab and then arrow keys, never by focusing an element from script — :focus-visible only matches for a keyboard, so a scripted focus would have photographed a different thing. Nothing was restyled to make the pictures look better; captures are at 3× (6× for the close-ups) and cropped to the rows.
1 · the basic caseA focused file row, with unfocused rows under it
deploy.sh
The four rows below are the same rows unfocused, so the difference is in the picture rather than in a description. The band starts and ends on the text, not on the name column: .tw-name is the flexible column that pushes Size and Modified to the right, so painting it would have left a long empty tail after a short filename. The paint sits on an inner span that is exactly as wide as the name.
2 · close upWhere the band starts, where it ends, and its corners
Square, because the rounding belonged to the row and the band no longer is the row. There is a quarter of an em of air each side of the text, and that padding is cancelled by an equal negative margin — so arrowing down a listing does not nudge every name sideways as the focus arrives. (Measured in the suite with a Range over the text node: the padded box moves, the glyphs do not.)
3 · a folderThe same thing on a folder row
docs
A folder row has no size and no download button, so the name column starts and ends in the same place but the row carries less. The band behaves identically — it is on the name, and short names get short bands.
4 · the stale pointerFocus on one row, the mouse resting on another
deploy.sh, pointer over docs
This is the case that decided the strength. Hover is a whisper across the whole row (--panel-2) and reveals that row's actions; focus is a definite mark on one name. They are different in kind — a row-wide wash versus a text-width block — and not just in degree, so a mouse left lying on the listing cannot be mistaken for where the keyboard is.
5 · the hard caseFocus on a row that is also selected
deploy.sh selected + focused · README.md selected only
Both rows are selected. The top one also has the keyboard. That is the whole question the accent band raised: accent on accent.
Two choices make it work. The row keeps saying what it is — the selected tint stays on the row — and the name says where the keyboard is, on top of it. And the name's colour changes: a selected name is normally accent at weight 600, which on an accent band is teal on teal (measured 3.68:1 in light, 2.16:1 in dark — unreadable), so when the band is there the text goes back to ordinary ink and keeps the weight. README.md in these shots is what a selected row looks like without the keyboard: accent text, no band.
Worth knowing: this combination cannot currently happen in the app. "Selected" means the file open in the preview, and the listing is hidden while a preview is open, so no row is ever both selected and on screen. The class was applied directly for these two pictures. The rule exists so the cascade is right if that ever changes, not because it is visible today.
6 · mid-dragFocus on the folder a drag would land in
README.md onto the focused docs
The drop target keeps everything it had: its own accent tint, its solid accent outline, and the dashed outline around the listing. The focus band sits on the name on top of that, so mid-drag you can still see which row the keyboard is on without the drop affordance being weakened. The dragged row is the dimmed one.
The numbers behind the choice
34% accent is the weakest tint that stays a clear step on every surface it can land on. Contrast ratios, measured on the real pane with the row states read from the cascade rather than written out again:
| the band is sitting on | light: band vs row | light: name on band | dark: band vs row | dark: name on band |
|---|---|---|---|---|
| a quiet row | 1.62:1 | 11.25:1 | 1.88:1 | 8.50:1 |
| a hovered row | 1.59:1 | 10.74:1 | 1.89:1 | 8.37:1 |
| a selected row | 1.54:1 | 9.85:1 | 1.88:1 | 6.87:1 |
| a drop target | 1.51:1 | 9.18:1 | 1.84:1 | 6.31:1 |
Weaker tints were measured too: at 22% the band falls to 1.30:1 on a drop target in light, which is where it stops being a mark and starts being a smudge.
What I would flag, now that I can see it
- The selected case is the weakest picture on this page. 1.54:1 is a real step and the shot shows it, but it is the one place where two accent tints sit on top of each other and the eye has to work. If it ever becomes reachable in the app, I would rather the focused name went to solid accent with light text than keep stacking tints — say the word and I will show that version rather than guess.
- A short name gives a short band.
docsis a small mark on a wide row. That is the direct consequence of "just over the file name" and I think it reads fine, but it is the trade against the full-row band, so it is worth seeing before it is accepted. - Nothing here was tuned for the photograph. These are the branch's values; if a case looks wrong, the fix belongs in the CSS rather than in the capture.