fix(dock): one washed-out fill per tab, and a border that says which is current #112

Merged

lz merged 3 commits from fix/tab-colour into rc/sidebar-96

2026-09-04 16:53:16 +02:00

lz commented

2026-09-04 16:40:45 +02:00

Owner

First of four addressing sidebar-issues against the release candidate.

The problem

dockview paints background-color on .dv-tab, which is the parent of the div SessionTab renders — so --accent-dim on the focused group's visible panel composited under the session wash rather than replacing it. The current tab rendered as yellow-green tinted by its session's hue: two colours over the same pixels, neither readable as itself.

Measuring also turned up something worse than the original report: dockview's --dv-activegroup-visiblepanel-tab-color: var(--accent) won on the active tab, so the selected tab read as the dimmest in the strip while the two unselected ones showed their names in full-strength colour.

The fix

A tab now has exactly one fill — its session wash — and which tab is current is a 2px bottom border in that same hue, reserved transparent on every tab so selecting one never shifts its text.

Text keeps its session colour on every tab, active included. Selection is the border's job; identity is the micro-caps line's and the glyph's, unconditionally.

all four --dv-*-tab-background-color → transparent
--dv-*-tab-color → --text / --muted, mirroring what the inner div sets
.dv-tab padding zeroed inside the tabs container — it inset the tab by 0.25rem 0.5rem, so the wash stopped 4px short of the edges and the border would have floated above the strip's baseline

Verification

Browser, against a seeded instance, measured off the live DOM: idle tabs carry their session hue on the micro-caps line and glyph with a transparent border and a 0.06 wash; the active tab carries the same hue at 0.14 plus a 2px border in it and a --text name. No --accent anywhere in the strip, at 1500px and at 420px.

Gates: typecheck 4897 files / 0 errors, lint clean, 120 files / 1200 tests.

Notes

--dv-activegroup-hiddenpanel-tab-color is not inert — .dv-tabs-overflow-dropdown-default (the "+N more" control dockview renders once the strip overflows) reads it directly. Verified live with five panels docked at 900px. There's a comment on the block saying so, because the earlier rationale invited deleting it as dead.

One deliberate loss: dockview distinguished the active tab of the focused group from that of an unfocused one. With all four backgrounds transparent those now look identical — split the dock into two groups and nothing says which has keyboard focus. Left out rather than inventing a fifth signal for a post-split-only case; cheap to add back as a dimmed border.

Based on rc/sidebar-96: the tab wash comes from feat/target-menu at the base of the #96 stack, so this does not apply to main as it stands.

First of four addressing `sidebar-issues` against the release candidate. ## The problem dockview paints `background-color` on `.dv-tab`, which is the **parent** of the div `SessionTab` renders — so `--accent-dim` on the focused group's visible panel composited *under* the session wash rather than replacing it. The current tab rendered as yellow-green tinted by its session's hue: two colours over the same pixels, neither readable as itself. Measuring also turned up something worse than the original report: dockview's `--dv-activegroup-visiblepanel-tab-color: var(--accent)` won on the active tab, so the **selected** tab read as the dimmest in the strip while the two unselected ones showed their names in full-strength colour. ## The fix A tab now has exactly one fill — its session wash — and which tab is current is a **2px bottom border in that same hue**, reserved transparent on every tab so selecting one never shifts its text. Text keeps its session colour on *every* tab, active included. Selection is the border's job; identity is the micro-caps line's and the glyph's, unconditionally. - all four `--dv-*-tab-background-color` → `transparent` - `--dv-*-tab-color` → `--text` / `--muted`, mirroring what the inner div sets - `.dv-tab` padding zeroed inside the tabs container — it inset the tab by `0.25rem 0.5rem`, so the wash stopped 4px short of the edges and the border would have floated above the strip's baseline ## Verification Browser, against a seeded instance, measured off the live DOM: idle tabs carry their session hue on the micro-caps line and glyph with a transparent border and a 0.06 wash; the active tab carries the same hue at 0.14 plus a 2px border in it and a `--text` name. **No `--accent` anywhere in the strip**, at 1500px and at 420px. Gates: typecheck 4897 files / 0 errors, lint clean, 120 files / 1200 tests. ## Notes `--dv-activegroup-hiddenpanel-tab-color` is **not** inert — `.dv-tabs-overflow-dropdown-default` (the "+N more" control dockview renders once the strip overflows) reads it directly. Verified live with five panels docked at 900px. There's a comment on the block saying so, because the earlier rationale invited deleting it as dead. **One deliberate loss:** dockview distinguished the active tab of the *focused* group from that of an *unfocused* one. With all four backgrounds transparent those now look identical — split the dock into two groups and nothing says which has keyboard focus. Left out rather than inventing a fifth signal for a post-split-only case; cheap to add back as a dimmed border. Based on `rc/sidebar-96`: the tab wash comes from `feat/target-menu` at the base of the #96 stack, so this does not apply to `main` as it stands.

lz added this to the Sidebar declutter, startup visibility & the target menu (#96) milestone

2026-09-04 16:40:45 +02:00

lz added 3 commits

2026-09-04 16:40:46 +02:00

fix(dock): one washed-out fill per tab, and a border that says which is current f2a3a73fea

The complaint was the tab BACKGROUND: dockview paints `background-color` on
`.dv-tab`, which is the PARENT of the div SessionTab renders, so `--accent-dim`
on the focused group's visible panel composited UNDER the session wash rather
than replacing it. The current tab rendered as yellow-green tinted by its
session's hue — two colours over the same pixels, neither readable as itself.

Now a tab has exactly one fill, its session wash, and which tab is current is a
2px bottom border in that same hue, reserved transparent on every tab so
selecting one never shifts its text.

Text keeps its session colour on EVERY tab, active included. That is a fix in
itself: dockview's `--dv-activegroup-visiblepanel-tab-color: var(--accent)` won
on the active tab, so the selected tab read as the DIMMEST in the strip while
the two unselected ones showed their names in full-strength colour. Selection
is the border's job; identity is the micro-caps line's and the glyph's,
unconditionally.

- all four `--dv-*-tab-background-color` → transparent: the wash is the only
  fill left.
- `--dv-*-tab-color` → `--text` / `--muted`, mirroring what the inner div sets.
  These land on a wrapper every text node already overrides, so the accent was
  invisible — and was a yellow-green inherited value waiting for the first child
  that forgot to set its own.
- `.dv-tab` padding zeroed inside the tabs container: it inset the tab by
  `0.25rem 0.5rem`, so the wash stopped 4px short of the edges and the border
  would have floated above the strip's baseline.

Verified in a browser against a seeded instance, measured off the live DOM:
idle tabs carry their session hue on the micro-caps line and glyph with a
transparent border and a 0.06 wash; the active tab carries the same hue at 0.14
plus a 2px border in it and a `--text` name. No `--accent` anywhere in the
strip, at 1500px and at 420px.

refactor(dock): keep the tab's wash alphas with the rest of the wash system d8b08a1fbf

Applying a /simplify finding. The two tab alphas were magic numbers shadowing
`--wash-row` inside SessionTab's scoped CSS, under a name that means "sidebar
row" everywhere else. app.css already generalises "the alpha scales with the
surface" as named `:root` tokens, and its comment claimed there were two of
them — so a pass over wash intensity would have edited those two and silently
missed the tab.

Named `--wash-tab` / `--wash-tab-active` next to `--wash-row` / `--wash-tile`;
the component now feeds them into `--wash-row` for `.washed` rather than
carrying the numbers itself. Rendered output is unchanged — measured off the
live DOM, idle tabs still resolve to 0.06 and the active tab to 0.14.

docs(dock): the tab-colour vars are not inert — one drives dockview's own chrome

ci / nexus (pull_request) Successful in 8m37s

Details

ci / images (pull_request) Successful in 14m21s

Details

pr-image-cleanup / delete-pr-images (pull_request) Successful in 17s

Details

4ef8f48dda

Applying a /simplify finding. The comment argued the four `--dv-*-tab-color`
vars only mirror what SessionTab sets, on the grounds that every text node
inside the tab overrides them. True of the tabs, and false of the block: the
"+N more" control dockview renders once the strip overflows
(`.dv-tabs-overflow-dropdown-default`) reads
`--dv-activegroup-hiddenpanel-tab-color` directly, with nothing of ours in
between and no overflow list disabled in Dock.svelte.

The rationale as written invited a later editor to delete the block as provably
inert, which would drop that control onto dockview's own default against a dark
palette. Values unchanged; the comment now names the real reason to keep it.

Verified live rather than by reading: five panels docked at 900px, the control
renders "2" and computes to `--muted`.

lz merged commit e1844df5f6 into rc/sidebar-96

2026-09-04 16:53:16 +02:00

lz referenced this pull request from a commit

2026-09-04 16:53:18 +02:00

Merge PR #112: one washed-out fill per tab, and a border for the current one

lz referenced this pull request

2026-09-04 17:29:48 +02:00

Land the sidebar-issues work from the release candidate onto main #116

lz referenced this pull request

2026-09-04 18:00:41 +02:00

fix(ui): five regressions the sidebar restyle and the token re-tier introduced #118

lz referenced this pull request from a commit