Describe the bug
The desktop app's theming is class-driven: ThemeProvider resolves the active
theme and sets .dark / .light on <html>
(desktop/src/shared/theme/ThemeProvider.tsx), and the synchronous bootstrap in
desktop/index.html seeds that class before first paint.
However, the app is on Tailwind v4, where the dark: variant defaults to
the prefers-color-scheme media query unless it is explicitly rebound to a
class. Neither desktop/src/shared/styles/globals.css nor the legacy config
loaded via @config declares such a binding (tailwind.config.js has no
darkMode key, and there is no @custom-variant anywhere in the repo).
The result: all 127 dark: utilities across 48 desktop files respond to the
OS appearance, while every CSS-variable-driven style responds to the
selected theme. Any user who picks an explicit theme that disagrees with
their OS appearance gets mixed styling.
To reproduce
- macOS in dark appearance.
- In Buzz: Settings → Appearance → mode Light, any light theme
(e.g. Catppuccin Latte).
- Look at surfaces styled with
dark: utilities, e.g. the message composer
(desktop/src/features/messages/ui/MessageComposer.tsx uses
dark:bg-background/70 dark:backdrop-blur-xl ...): they apply their
dark-mode treatment on top of the light theme.
- The inverse also holds (OS light + explicit dark theme):
dark: styling
silently never applies.
Evidence (compiled CSS)
Compiling desktop/src/shared/styles/globals.css with the repo's own config
(Tailwind CLI 4.3.x) emits every dark: utility inside a media query — there
is no .dark-class selector at all:
@media (prefers-color-scheme: dark) {
.dark\:border-blue-500\/30 { ... }
.dark\:bg-background\/70 { ... }
/* ...every dark: utility in the app... */
}Expected behavior
dark: utilities should follow the theme class the app already maintains, i.e.
compile to .dark\:bg-background\/70:where(.dark, .dark *) { ... }.
Why it goes mostly unnoticed
The default is "Buzz + Follow system", so theme and OS agree for most users.
Only users who pin a theme that disagrees with their OS appearance see the
mismatch — which may also be a contributing factor in other light-mode
visibility reports.
Fix
One line in each Tailwind entry point (desktop and web, which has the same
latent pattern — its ThemeProvider also sets the class):
@custom-variant dark (&:where(.dark, .dark *));
Verified by recompiling: zero prefers-color-scheme occurrences remain and all
dark: utilities bind to the theme class. PR incoming.
Environment
- Found by static analysis + compiling the stylesheet with the repo's config
(Tailwind CLI 4.3.3); reproducible on any platform.
Describe the bug
The desktop app's theming is class-driven:
ThemeProviderresolves the activetheme and sets
.dark/.lighton<html>(
desktop/src/shared/theme/ThemeProvider.tsx), and the synchronous bootstrap indesktop/index.htmlseeds that class before first paint.However, the app is on Tailwind v4, where the
dark:variant defaults tothe
prefers-color-schememedia query unless it is explicitly rebound to aclass. Neither
desktop/src/shared/styles/globals.cssnor the legacy configloaded via
@configdeclares such a binding (tailwind.config.jshas nodarkModekey, and there is no@custom-variantanywhere in the repo).The result: all 127
dark:utilities across 48 desktop files respond to theOS appearance, while every CSS-variable-driven style responds to the
selected theme. Any user who picks an explicit theme that disagrees with
their OS appearance gets mixed styling.
To reproduce
(e.g. Catppuccin Latte).
dark:utilities, e.g. the message composer(
desktop/src/features/messages/ui/MessageComposer.tsxusesdark:bg-background/70 dark:backdrop-blur-xl ...): they apply theirdark-mode treatment on top of the light theme.
dark:stylingsilently never applies.
Evidence (compiled CSS)
Compiling
desktop/src/shared/styles/globals.csswith the repo's own config(Tailwind CLI 4.3.x) emits every
dark:utility inside a media query — thereis no
.dark-class selector at all:Expected behavior
dark:utilities should follow the theme class the app already maintains, i.e.compile to
.dark\:bg-background\/70:where(.dark, .dark *) { ... }.Why it goes mostly unnoticed
The default is "Buzz + Follow system", so theme and OS agree for most users.
Only users who pin a theme that disagrees with their OS appearance see the
mismatch — which may also be a contributing factor in other light-mode
visibility reports.
Fix
One line in each Tailwind entry point (desktop and web, which has the same
latent pattern — its
ThemeProvideralso sets the class):Verified by recompiling: zero
prefers-color-schemeoccurrences remain and alldark:utilities bind to the theme class. PR incoming.Environment
(Tailwind CLI 4.3.3); reproducible on any platform.