Skip to content

fix(ui): drawer polish — themed select carets, centred view controls - #13

Merged
Seanathon merged 1 commit into
mainfrom
fix/drawer-select-carets-and-view-controls
Aug 19, 2026
Merged

fix(ui): drawer polish — themed select carets, centred view controls#13
Seanathon merged 1 commit into
mainfrom
fix/drawer-select-carets-and-view-controls

Conversation

@Seanathon

Copy link
Copy Markdown
Owner

Follow-up to #12. Three things reported from the drawer on a real phone, plus one found while verifying them.

Select carets were native, so every engine drew its own

White on macOS Chrome and Firefox (they honour color-scheme), black on iOS Firefox (it does not), and each engine set its own inset — which is why the arrow sat almost against the border on desktop. Replaced with a drawn chevron that swaps per theme via a --select-caret custom property, with real right padding.

This also sets color-scheme on the root, which fixes something separate and worse: the open dropdown list and the scrollbars were rendering from the OS theme, so a dark app was getting a white option list.

One rule covers all five selects (facet filters, sort, library type, and the JS-built descriptor facets) because they all share .filter-select.

The VIEW controls were not centred

.view-btn and .theme-toggle only centre on the cross axis, so once given a min-width in the drawer their icons sat left-aligned in the box. The sort select now takes its own full-width line — at ~292px of drawer width it could not share a row with both icon controls without crushing "Recently added" — and the two icon controls sit below it, all 44px, icons centred.

The branch elbow crossed the active board

It reached 8px up into the pill's rounded corner, which showed badly in light mode. It now starts at the 2px row gap and is painted accent, so it reads as one continuous gesture from the selected board into its action.

Found while verifying

openDrawer added its .open class inside a requestAnimationFrame. rAF is throttled in a backgrounded or occluded tab, so the class could fail to land and leave a focus-trapped dialog rendered off-screen with hidden already false. Forces a reflow and opens in the same task instead. I hit this for real in the test browser, which is the only reason I found it.

Also gives the ⚙ glyph a U+FE0E variation selector so iOS renders it as text rather than a colour emoji, which is what it was doing in the reported screenshot.

Verification

591 tests and typecheck green. Driven in both themes at 400px and on desktop: all five selects carry the themed caret with appearance: none, no console errors across all five boards, drawer closes and releases the scroll lock on every switch, no horizontal overflow.

Note

This touches desktop deliberately in one place — the caret inset — because the report was explicitly about desktop ("the carets in desktop browser are too close to the edge of the select box"). Nothing else in the diff applies above 900px.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C83mrW9X8zBLY1sSZRgdCa

Three things reported from the drawer on a real phone, plus one found
while verifying them.

Select carets were native, so every engine drew its own: white on macOS
Chrome and Firefox (they honour color-scheme), BLACK on iOS Firefox
(it does not), each with its own inset that sat the arrow almost against
the border. Replaced with a drawn chevron that swaps per theme, with
real right padding. Also sets `color-scheme` on the root, so the OPEN
dropdown list and scrollbars follow the app's theme instead of the OS —
a dark app was getting a white option list.

The VIEW controls were not centred: .view-btn and .theme-toggle only
centre on the cross axis, so once given a min-width their icons sat
left-aligned in the box. The sort select now takes its own full-width
line (at ~292px of drawer width it could not share a row with both icon
controls without crushing "Recently added") and the two icon controls
sit below it, all 44px, icons centred.

The branch elbow under the active board reached 8px up into the pill's
rounded corner and crossed it, which showed badly in light mode. It now
starts at the 2px row gap and is painted accent, so it reads as one
continuous gesture from the selected board into its action.

Found while verifying: openDrawer added its .open class inside a
requestAnimationFrame. rAF is throttled in a backgrounded or occluded
tab, so the class could fail to land and leave a focus-trapped dialog
rendered off-screen with `hidden` already false. Forces a reflow and
opens in the same task instead.

Also gives the ⚙ glyph a U+FE0E variation selector so iOS renders it as
text rather than a colour emoji, which is what it was doing in the
reported screenshot.

591 tests green. Verified in both themes at 400px and on desktop: all
five selects carry the themed caret, no console errors, drawer closes
and releases the scroll lock on every board switch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C83mrW9X8zBLY1sSZRgdCa
@Seanathon
Seanathon merged commit 41a4227 into main Aug 19, 2026
2 checks passed
@Seanathon
Seanathon deleted the fix/drawer-select-carets-and-view-controls branch August 19, 2026 11:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant