Add dark mode support for content frame

[shaunandrews]

Summary

• Add system-preference dark mode (prefers-color-scheme: dark) for the content frame area while keeping the sidebar chrome permanently dark
• Define 14 CSS custom properties (--color-frame-*) with dark mode overrides, mapped to Tailwind tokens (frame-*)
• Enable Electron nativeTheme.themeSource = 'system' so the renderer respects OS preference
• Add dark mode CSS override block using :is() for WP component classes (inputs, buttons, tabs, modals, popovers, menus)
• Make the Button component dark-mode-aware by replacing hardcoded text-black/bg-white with frame-* tokens
• Migrate ~40 component files from hardcoded colors (text-gray-*, bg-white, border-gray-*, hex values) to semantic frame-* tokens
• Remove two "What's New" pages (selective sync, Pressable sync)

Test plan

• Toggle system appearance to dark mode and verify the content frame background changes to #2F2F2F
• Verify sidebar chrome remains unchanged in both modes
• Check all 6 content tabs (Overview, Sync, Previews, Import/Export, Settings, Assistant)
• Open the "Add a site" fullscreen modal and verify all text, inputs, and buttons are readable
• Open WP modals (Connect site, Edit site) and verify dark surfaces and text
• Check dropdown menus (preview site actions, assistant chat menu)
• Verify primary (blue) and destructive (red) button colors are preserved
• Test the assistant chat: messages, welcome prompts, input bar, Telex banner
• Switch back to light mode and verify no regressions

[wojtekn]

Hey @shaunandrews ! Thanks for working on that - it looks like an interesting addition. I think it would make sense to do the following before we pass it for review:

• Adding a setting allowing the user to choose between light mode, dark mode, and “follow system default” modes
• Adding e2e tests for new changes
• Fixing all failing builds

You could also consider adding it to the What's New dialog.

[shaunandrews]

I've updated the settings screen:

• I've added a new appearance setting for system, light, and dark modes. This setting is changes immediately, without having to click the save button.
• The new appearance setting has a tendency to cause the settings modal to scroll vertically, hiding the save button. To avoid this, I've removed some of the size restrictions around the modal height, and put the editor and terminal settings on the same row.
• I visually aligned the CLI switch with the first row of text.

[shaunandrews]

I also added to the What's new modal:

[wpmobilebot]

📊 Performance Test Results

Comparing f723f91 vs trunk

app-size

Metric	trunk	f723f91	Diff	Change
App Size (Mac)	1236.42 MB	1236.49 MB	+0.07 MB	⚪ 0.0%

site-editor

Metric	trunk	f723f91	Diff	Change
load	1925 ms	1648 ms	277 ms	🟢 -14.4%

site-startup

Metric	trunk	f723f91	Diff	Change
siteCreation	7095 ms	7099 ms	+4 ms	⚪ 0.0%
siteStartup	3923 ms	3918 ms	5 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[wojtekn]

@shaunandrews, thanks for adding settings UI. Some notes regarding UX:

• Currently, settings are not saved until the user presses Save, and it's different for dark mode. I think the new way is okay too, but it would be better to stick to one of those ways and use the same approach for all options.
• The buttons look a bit too expressive - do they add any value? What if we just used buttons with small icons inside?

[shaunandrews]

I made the appearance setting save immediately because it helps the user understand what the setting does as they can see the UI of the main window change immediately. I'm not opposed to changing the rest of the settings to work similarly, but this PR is already huge; would be a good follow up.

As for the buttons, I did try other options but felt the illustrations looked much better and helped convey the settings effects better than an icon. It's also a fairly standard pattern.

[sejas]

@shaunandrews, thanks for creating this PR. I tested the app holistically and only found a few places where we could improve the colors for accessibility reasons. There were some conflicts, and I pushed a commit to fix them and pull the latest changes from trunk 1d084ed

I suggest collaborating next week to bring this PR over the finish line. Thank you!

Here are the components that I identified as needing improvement:

Push warning

Site title to connect sites

AI animated icon and maybe arrows links
Some links are difficult for me to identify; they are clickable.

File icons on selective push

Password input in site settings

I think it's too bright-white.

Here is a video with all my testing:

light-dark-mode-web.mp4

[shaunandrews]

Thanks for the review! I've got through and fixed a bunch! I wasn't able to change the Rive animation for the Assistant tab input, but I don't think that's a blocker. (I honestly kind of hate it, and would rather just remove it than generate a dark-mode variant.)

WP component overrides (index.css)

• Modals: Override Emotion's background: white on modal frames so they render with the dark frame background. Fixed header border that was always visible (now only shows when content scrolls). Replaced light box-shadow with a darker one appropriate for dark backgrounds.
• Input controls: Override Emotion's white container backgrounds on input/search controls. Fixed the search icon prefix area that showed a lighter background behind the magnifying glass.
• Primary buttons: Force dark mode theme blue (#6b8aff) with proper hover (#8da6ff) instead of WP's default calculated hover.
• Link buttons: Hover now turns blue (frame-theme) instead of light gray.
• Notices: Added dark mode surface/text overrides for WP Notice component.
• Span cascade: Split the blanket span color override to exclude spans inside buttons, fixing arrows and link text that were forced white regardless of their parent's color.
• Minimal selects: Preserved the borderless/transparent style for variant="minimal" selects in dark mode.
• Skeleton loading: Gradient now uses frame tokens instead of hardcoded light grays.

Component token migration (~30 files)

Replaced hardcoded text-a8c-gray-50/70/700/30, fill-a8c-gray-*, border-gray-*, and bg-gray-* with semantic frame-text-secondary, frame-border, and frame-surface tokens across all content frame components — including settings, assistant, sync, previews, import/export, onboarding, add-site, and user settings.

Site selector & badges

• Hover state: Changed from bg-a8c-blue-5 (invisible on dark) to bg-frame-surface.
• Selected state: Site name now uses !text-white to override the .a8c-body dark mode cascade. WordPress logo icon uses frame token for disabled state.
• Environment badges: Production/staging use fixed colors that pass WCAG contrast on both backgrounds. Selected badge is white fill with theme-blue text.

Input controls

• Password control: Replaced hardcoded border-[#949494], bg-gray-100, text-gray-500 with frame tokens. Eye icon uses fill-frame-text-secondary.
• Text control: Replaced hardcoded disabled grays with opacity approach.

Tree view & sync dialog

• File/folder icons: Added fill-frame-text so WP icons are visible on dark backgrounds.
• Minimal select: Added select-minimal class to preserve the borderless style in the sync file picker.

[sejas]

I'll make one last review and push some small fixes if I find anything.

[sejas]

Thanks for adjusting the PR. I just pushed a fix for notices. f723f91

Light	Dark

I also confirm that the rest of the improvements were fixed. The only exception would the Rive AI animation.

Passowrd input

Files icons

Learn more and arrow icons

Site selection

[shaunandrews]

doh, i missed the notice! thanks for the fix