Light mode issue

[unknowdeepanshu]

hey i just wondering the all developer used dark mode for search components in shadcn website and there light mode found issue in website as you can see in red box there color in components still show in dark mode :-

it's ok ? raise issue or just ignore ?

[Mahiisss]

Worth raising, yeah — but check one thing first, because it changes what the bug actually is.

Is your OS or browser set to dark mode right now?

shadcn uses class-based dark mode — Tailwind's darkMode: "class", with a .dark class toggled on <html>. So the theme switcher works by adding and removing that class, and nothing should care what your system is set to.

But if a component is styled with @media (prefers-color-scheme: dark) instead of the dark: class variant, it ignores the toggle completely and just follows your OS. That's exactly what you'd see here: page flips to light, but a few elements stay stubbornly dark.

So:

• OS is in dark mode → likely a media-query leak somewhere in those components. Real bug, and a useful one to report because it points straight at the cause.
• OS is in light mode → different bug. Something's hardcoding dark colors rather than using theme tokens.

Quick way to check: open DevTools, inspect one of the elements in your red box, and look at which rules are applying. If you see a prefers-color-scheme media query in there, that's your answer.

Also try a hard refresh (Ctrl+Shift+R) and a different browser before reporting — occasionally it's just stale CSS.

If it still reproduces, open it as an issue rather than leaving it here, and include:

• the exact page URL
• browser + version
• whether your OS theme is light or dark
• your screenshot (the red boxes are genuinely helpful)
• whether it survives a hard refresh

One caveat — that left panel is the theme customizer, and it's possible the dark treatment there is deliberate design rather than a bug. The 01 02 element bottom-right looks more clearly wrong. Might be worth mentioning both but flagging which one you're more confident about, so they can triage it quickly.

[MarvelCollin]

this is worth reporting as an issue. the left sidebar/command palette area being dark is intentional design, thats consistent across both themes. but the search result items inside it should still follow whatever theme is active.

what is likely happening is that some of the styles on those elements are using @media (prefers-color-scheme: dark) instead of the tailwind dark: class variant. shadcn uses class based dark mode, meaning it adds a .dark class to the html element when you toggle the theme. but if any component style falls back to the media query approach, it will follow your OS setting instead of the in-app toggle. so if your OS is set to dark mode and you switch the site to light mode, those specific elements stay dark because they are listening to the OS, not the class.

you can verify this by opening devtools on one of those elements in the red box and checking computed styles. look at where the background color is coming from. if it says something like @media (prefers-color-scheme: dark) thats the bug. if it comes from a .dark ancestor class then something else is going on.

either way open it as an issue with your screenshot, your OS theme setting, and the browser you are using. that gives them everything they need to track it down.

[unknowdeepanshu]

@MarvelCollin and @Mahiisss thanks for suggestion
i am going the open the issue

[nhannm-vn]

This is by design, not a bug!

The sidebar panel on the left (and the code snippet preview controls) is intentionally styled with dark mode to represent a fixed developer control panel / customizer UI. It allows users to configure themes, styles, colors, and fonts independently without changing the customizer's own UI state.

Key Reasons:
UI Customizer Boundary: The dark sidebar functions as an isolated toolbar/control layer, maintaining consistent contrast regardless of whether the preview workspace is set to Light or Dark mode.

No Need for an Issue: Since it's an intentional design choice for the shadcn website's interactive docs, opening an issue isn't necessary.

If this answers your question, please consider marking it as the answer to help others!

[unknowdeepanshu]

@nhannm-vn might issue regarding for as you can see in video. In light mode there is 5 components still dark mode

video-1790005077778.mp4

[kxrn-gupta]

Looking closely at your attached video reproduction, the issue is that the customizer sidebar itself is wrapping several preview sub-components inside a scoped theme container with a hardcoded or inherited .dark class rather than following the global html root state.

Root Cause Breakdown:

1. Isolated Component Scoping: The theme customizer page wraps those 5 specific preview components inside a container that has class="dark bg-background text-foreground". Even when you toggle the global document theme switcher to light mode (<html class="light">), the nested container maintains its own .dark class cascade.
2. Missing Theme Context Sync: The global next-themes provider's toggle only targets the document.documentElement class list. Nested sub-trees with explicit .dark containers won't re-render unless explicitly connected to the active theme context hook.

How to Fix this in your own project:

If you are replicating this layout in your own Next.js / Vite application and want all nested blocks to reliably flip between light and dark:

1. Use ThemeProvider from next-themes with attribute="class":

import { ThemeProvider } from "next-themes"

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <ThemeProvider attribute="class" defaultTheme="system" enableSystem>
      {children}
    </ThemeProvider>
  )
}

2. Ensure Container Scoping doesn't hardcode .dark:
   Check the wrapper div around your preview cards and make sure it uses CSS variables (bg-card text-card-foreground) rather than hardcoding Tailwind dark utilities:

// ✅ Correct (dynamically inherits theme tokens):
<div className="rounded-lg border bg-card p-6 text-card-foreground shadow-sm">
  {/* Component content */}
</div>

// ❌ Incorrect (forces dark styling regardless of light toggle):
<div className="dark bg-zinc-950 text-zinc-50">
  {/* Will remain dark */}
</div>

This explains why the documentation preview shows that behavior for those 5 components. In your own apps, relying on CSS variables mapped to :root and .dark will keep all components perfectly in sync.

(Pro-tip: If you are testing cross-browser theme hydration and dark-mode SSR in isolated environments, Microsoft Azure Student Developer Resources offer free student cloud instances for continuous deployment testing).