Left-sidebar seam — window edge & titlebar

Status, 20 Sep 2026: the 24px flank ("today" below) shipped fixed in 5851bbb6, the bottom gap in 1c563b29, the scroll slip in d7710610. The "today" figures are the pre-fix state. The surface behind the detail pane was measured on macOS 27 as pure #ffffff — neither of the two greys the behind detail pane toggle offers — so A's contrast rows are wrong for 27 (A ≡ D there, and OS-dependent). Decision: the panel keeps its tint as is; matching the native sidebar material is not attempted.

Three ways the Codebook navigator's background could meet the window's left edge and the titlebar. Studies option A (transparent), B (opaque tint bleeding up through a transparent titlebar), and D (stop joining). Real tokens; the macOS materials are labelled approximations.

appearance
palette
native sidebar
behind detail pane
Artefact — the pixels as they would ship Commentary — reasoning, never the product

Today as shipped, 0.29.1

Opaque panel tint, 24px of transparent body padding on each flank, opaque titlebar.

today
▣
☰
project-ikea7 Codebooks · 147 Tags
↥
▥
⌕
Project
Sessions
Quotes
Codebooks
Analysis
Projects
project-ikea

the gapbody { padding: var(--bn-space-xl) var(--bn-space-lg) } — report.css:21. The embedded override at report.css:36 replaces only padding-top, so 24px of horizontal padding survives in the app. The embedded body is background: transparent, so that 24px shows the window surface through it — a third light grey between the native material and the panel tint. Same cause on both flanks, and the same cause whether the native sidebar is open or closed.

the topThe panel is opaque by contract (_contract.css:27: “opaque so it reads over the vibrant body in desktop frosted mode”) and stops dead at the toolbar seam. Meanwhile report.css:24 says the body was made transparent so the frost has real content to sample. The build does both at once, so the frost samples flat colour.

A — transparent panel the window's own surface shows through

Drop the panel's opaque tint. Nothing to extend: it is already continuous to the window edge and up under the titlebar, because it is the window's surface.

A · transparent
▣
☰
project-ikea7 Codebooks · 147 Tags
↥
▥
⌕
Project
Sessions
Quotes
Codebooks
Analysis
Projects
project-ikea

bitrot-proofNothing is matched, so nothing can drift. This is design-native-colour-alignment.md §Principles' “Best” tier by construction: the OS owns the colour and we never sample it. macOS 27 costs nothing.

the open questionFlip the “behind detail pane” toggle above. With sidebar material it is seamless. With window background you get a different mismatch — the panel now disagrees with the native sidebar instead of agreeing with it. Which one it really is decides whether A works, and no amount of source reading settles it. One screenshot does.

contrastRow text now sits on a vibrant material rather than a known hex. --bn-colour-text over live vibrancy is not the case any of the sampled ratios in the colour doc were measured against; Increase Contrast and Reduce Transparency both need a look.

B — opaque tint, bleeding up through the titlebar the Xcode navigator idiom

Keep the tint; zero the 24px; bleed the panel background to the window top behind a transparent titlebar. Rows stay on the datum — only the background moves.

B · bleed to titlebar
▣
☰
project-ikea7 Codebooks · 147 Tags
↥
▥
⌕
Project
Sessions
Quotes
Codebooks
Analysis
Projects
project-ikea

the number existsBridgeHandler.syncToolbarInset() already computes let nativeInset = webView.safeAreaInsets.top at line 550 — exactly how far up the panel must bleed — and then discards it, posting only the residual (0 today). Post nativeInset as a second variable and the existing margin-top bleed pattern does the rest. It rides a channel already re-fired on ready, fullscreen enter/exit and every resize (ContentView.swift:643-657), so no new staleness.

the frost goes asymmetricLook at the toolbar above, left half vs right. Once the tint runs up behind it, the frost samples flat panel tint on the left and content white on the right. That step under the toolbar can read worse than the hard edge it replaces — and it is the part no amount of bridged geometry fixes.

OS exposureParts 1–2 (bridge the number, bleed by it) are OS-agnostic. Part 3 — the transparent titlebar itself — is the only piece macOS 27 can move, and it re-opens the spike BRANCHES.md:282 closed as “not proposed for ship in current form”.

D — stop joining the divider is the point

The navigator takes the content background and the split divider reads as an intended boundary. Two honest surfaces instead of one failed weld.

D · intentional boundary
▣
☰
project-ikea7 Codebooks · 147 Tags
↥
▥
⌕
Project
Sessions
Quotes
Codebooks
Analysis
Projects
project-ikea

freeOne CSS change plus the 24px fix. Zero OS exposure, zero Swift, zero new bridge values. macOS 27 cannot touch it.

arguably truer IAThe navigator is content-level navigation (which codebook am I reading?), not window chrome. Giving it the inspector tint claims it as a second sidebar, which is what makes the mismatch with the real one legible in the first place. design-sidebar-ia.md's split — left is structure, right is context — supports this reading.

it flattens the hierarchyThe tint exists so the content holds the highest contrast and the chrome recedes. D gives the panel --bn-colour-bg — the content background — so panel and content become literally identical (ratio 1.000). Of the three, D is the only one that actually commits the failure this study is trying to avoid. Cheapness does not rescue it.

it answers a different questionYou asked how to extend the background. D declines to. Worth naming plainly rather than letting it win on cost alone.

Seam magnifier commentary device — not the product

The left-edge layer stack, ~8× horizontally, native sidebar open. Left to right: sidebar material, NSSplitView divider, then whatever the webview puts down.

today
material · divider · 24px show-through · tint · border · content
four edges in ~30px
A · transparent
material · divider · window surface · border · content
one edge, if the two surfaces match
B · opaque, full-bleed
material · divider · tint · border · content
two greys, one divider — the match still has to hold
D · stop joining
material · divider · content · border · content
one deliberate boundary, nothing to match

Today's strip is the diagnosis: four edges inside ~30px, three of them unintended. A and D each remove two. B removes one and keeps the matching obligation — which is the one that gets re-paid at every OS bump.

Hierarchy check measured, not eyeballed

The reason the flanking panels are tinted at all: the main content area should hold the highest contrast, and the chrome either side of it should recede. Left nav and the Quotes tag sidebar share that job. So the question for each option is not only “is the seam clean” but “does the panel still sit below the content”.

today · tint
#f9f9fa → #ffffff
1.052 · ΔL 5.2%
A · material
~#f0f0f0 → #ffffff
1.140 · ΔL 12.9%
A · window bg
~#ececec → #ffffff
1.181 · ΔL 16.1%
D · content bg
#ffffff → #ffffff
1.000 · no separation

Transparent is not the same as white. The embedded body is background: transparent over a drawsBackground=false webview, so a transparent panel shows the window surface — which is darker than content, not equal to it. On the numbers, A roughly triples the panel/content separation rather than removing it. It is the option that serves this hierarchy best, not worst.

And the tint is barely doing the job today. #f9f9fa against #ffffff is 1.052 — the palette comment calls it “~2% off white”, and theme/CLAUDE.md already records that when the TOC panel sat on --bn-colour-bg the difference was “invisible in light mode (2% delta)”. The hierarchy being defended here is mostly notional in light; the tint earns its keep in dark, where it lifts the panel off a near-black editor (1.110, and 1.316 against material).

Which suggests a fourth reading. If the content-first hierarchy is the goal, the honest move is not “tint or no tint” but make the tint actually separate — deepen it toward the material's ~13% and bleed it full-width and up (B with a real value). That keeps the intent, fixes the seam, and stops defending a 5% delta as though it were doing structural work.

What this mockup cannot settle. The behind detail pane toggle is a real unknown, not a presentation choice. If the surface behind the detail column is the sidebar material, A is seamless and free. If it is windowBackgroundColor, A trades one mismatch for another and B or D wins. That is a screenshot, not an argument.

Separately, and not a seam problem. .toc-sidebar is missing display: flex; flex-direction: column, which its twin .tag-sidebar has (sidebar.css:190 vs :530). Its .toc-sidebar-body { flex: 1 } is therefore inert, so the outer panel scrolls instead of the body — taking the header and the datum with it. That is the vertical-alignment slip, it is present in every option above, and none of them fix it.