Summary
In release builds of WaveFlow with the Liquid skin + light theme, the Mood Radio tiles on the Home view are bleached to near-white instead of showing the colored gradient backdrop. Text (Focus, Chill, …) becomes nearly invisible against the pale tile body.
Dev (bun run tauri dev) renders the tiles correctly. The issue is only visible in bun run tauri build artifacts.
Reproduction
- Pick Liquid skin in
Settings → Appearance.
- Pick any light theme (Émeraude / Sunset / Lavender / …).
- Open the Home view with an analyzed library.
- Compare a dev build vs a release build — the Mood Radio row is dramatically washed out in release.

Root cause
liquid.css ships a "modals / tooltips / popovers" rule that substring-matches [class*="shadow-lg"] to repaint Tailwind popovers as Big-Sur frosted material:
:root[data-skin="liquid"]:not(.dark) :where(
[role="dialog"], [class*="shadow-lg"], [class*="shadow-xl"], [class*="shadow-2xl"]
) {
background-color: color-mix(in srgb, white 92%, transparent) !important;
}
The Mood Radio tile button in MoodRadioGrid.tsx carries hover:shadow-lg as part of its className. The substring matcher [class*="shadow-lg"] matches hover:shadow-lg (literal substring), so the tile inherits the 92%-opaque white panel treatment — drowning the colored ::before gradient.
Specificity is (0,2,1) on both the .liquid-mood-tile rule and the modal rule, so source order breaks the tie in favour of the modal rule (it comes later in the stylesheet).
Why only in release build?
The CSS rule cascade is the same in dev and prod, but Lightning CSS (Tailwind v4's production minifier) reorders / merges rules in ways that surface this latent specificity tie deterministically in prod, while Vite's dev CSS injection happens to preserve the per-import order such that the .liquid-mood-tile rule wins on the wire in dev. The fix removes the dependency on source order entirely.
Fix
Exclude .liquid-mood-tile from both [class*="shadow-lg"] modal rules in src/styles/skins/liquid.css:
:root[data-skin="liquid"] :where(
[role="dialog"], [role="tooltip"],
[class*="shadow-lg"], [class*="shadow-xl"], [class*="shadow-2xl"]
):not(.liquid-mood-tile) { /* … */ }
:root[data-skin="liquid"]:not(.dark) :where(
[role="dialog"],
[class*="shadow-lg"], [class*="shadow-xl"], [class*="shadow-2xl"]
):not(.liquid-mood-tile) { /* … */ }
Studio / Editorial / Lounge / Pulse skins don't need an analogous exclusion — their tile classes don't conflict with a [class*="shadow-*"] capture rule.
Acceptance
Target: v1.6.0.
Summary
In release builds of WaveFlow with the Liquid skin + light theme, the Mood Radio tiles on the Home view are bleached to near-white instead of showing the colored gradient backdrop. Text (
Focus,Chill, …) becomes nearly invisible against the pale tile body.Dev (
bun run tauri dev) renders the tiles correctly. The issue is only visible inbun run tauri buildartifacts.Reproduction
Settings → Appearance.Root cause
liquid.cssships a "modals / tooltips / popovers" rule that substring-matches[class*="shadow-lg"]to repaint Tailwind popovers as Big-Sur frosted material:The Mood Radio tile button in
MoodRadioGrid.tsxcarrieshover:shadow-lgas part of its className. The substring matcher[class*="shadow-lg"]matcheshover:shadow-lg(literal substring), so the tile inherits the 92%-opaque white panel treatment — drowning the colored::beforegradient.Specificity is
(0,2,1)on both the.liquid-mood-tilerule and the modal rule, so source order breaks the tie in favour of the modal rule (it comes later in the stylesheet).Why only in release build?
The CSS rule cascade is the same in dev and prod, but Lightning CSS (Tailwind v4's production minifier) reorders / merges rules in ways that surface this latent specificity tie deterministically in prod, while Vite's dev CSS injection happens to preserve the per-import order such that the
.liquid-mood-tilerule wins on the wire in dev. The fix removes the dependency on source order entirely.Fix
Exclude
.liquid-mood-tilefrom both[class*="shadow-lg"]modal rules insrc/styles/skins/liquid.css:Studio / Editorial / Lounge / Pulse skins don't need an analogous exclusion — their tile classes don't conflict with a
[class*="shadow-*"]capture rule.Acceptance
AudioPipelinePopover,MoreActionsMenu,SmartPlaylistEditor, etc.).Target: v1.6.0.