Skip to content

feat: default-theme links follow the macOS accent color#19

Merged
jnahian merged 1 commit into
mainfrom
claude/macos-accent-color-ipvc71
Jul 9, 2026
Merged

feat: default-theme links follow the macOS accent color#19
jnahian merged 1 commit into
mainfrom
claude/macos-accent-color-ipvc71

Conversation

@jnahian

@jnahian jnahian commented Jul 9, 2026

Copy link
Copy Markdown
Owner

Summary

The native chrome already tracks the macOS accent color (via Color.accentColor), but the rendered markdown content pane did not — links, heading anchors, and markers used a fixed per-theme --accent CSS variable, so they ignored the accent the user picked in System Settings.

This wires the content pane's standard theme to the system accent:

  • MarkdownWebView resolves NSColor.controlAccentColor under the active appearance (it maps to a different concrete color in light vs dark) and flattens it to a #rrggbb string.
  • It pushes that to a new window.ReaderMd.setAccent(hex) in bridge.js, which applies it as an inline --accent only on the standard theme. The Editorial and Terminal reading themes own their palettes, so the inline override (which would win over their html[data-theme] rules) is removed while one of those is active.
  • Re-pushes on accent change (NSColor.systemColorsDidChangeNotification) and on light/dark change, and replays on the web view's ready — mirroring the existing setTheme / setReadingTheme flow.

Chrome and Color.accentColor are untouched.

Related issue

Closes #

Testing

I don't have a macOS toolchain in this environment (the app needs the macOS 26 SDK; swift isn't available on Linux), so this has not been built or run yet. bridge.js passes node --check. Please verify locally:

  • Built and ran with swift run
  • Verified the affected flow in the app

Manual checks to run:

  • In the default theme, links/anchors take the System Settings → Appearance accent color; changing the accent updates the open document live; toggling light/dark keeps it correct.
  • Switching to the Editorial / Terminal reading themes restores their own accents; switching back to standard re-applies the system accent.

Checklist

  • macOS 26-only APIs are guarded with a pre-26 fallback (deployment target is 13) — no 26-only APIs used; performAsCurrentDrawingAppearance is macOS 11+
  • Imperative actions follow the token-bump pattern on AppState — follows the existing setTheme/setReadingTheme replay pattern in MarkdownWebView
  • Change is focused; matches surrounding code style

🤖 Generated with Claude Code

https://claude.ai/code/session_01XuYtHEiHpVijSVh6wrrdi1


Generated by Claude Code

The content pane's link/anchor/marker color came from a fixed per-theme
`--accent` CSS variable, so it ignored the accent the user picked in System
Settings — even though the native chrome already tracks it via
`Color.accentColor`.

Resolve `NSColor.controlAccentColor` (per light/dark) to a hex string and push
it to bridge.js as `setAccent`, which applies it as an inline `--accent` on the
standard theme only. The Editorial/Terminal themes own their palettes, so an
inline override (which would win over their `html[data-theme]` rules) is removed
while one of those is active. Re-pushes on accent change
(`systemColorsDidChangeNotification`) and on light/dark change, and replays on
the web view's `ready` — mirroring the existing setTheme/setReadingTheme flow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XuYtHEiHpVijSVh6wrrdi1
@jnahian jnahian marked this pull request as ready for review July 9, 2026 15:01
@jnahian jnahian merged commit 263af08 into main Jul 9, 2026
1 check passed
@jnahian jnahian deleted the claude/macos-accent-color-ipvc71 branch July 9, 2026 18:09
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.

2 participants