Theming + dark mode + Tailwind v4

[adrianthedev]

[!IMPORTANT]
This feature is on hold until TailwindCSS 4.0 lands in the fall.

This will probably land as a Pro or Advanced feature considering the high level of complexity.

Definitely follow the lead on Flux UI and Daisy UI.

Must have's

• [ ] Dark mode support. Should a theme have both variants?
• [ ] Should use CSS variables
• [ ] should support the following properties
  • [ ] colors
    • [ ] primary
    • [ ] secondary
    • [ ] background
    • [ ] text
    • [ ] heading
    • [ ] link
    • [ ] border
  • [ ] fonts
    • [ ] line-spacing
  • [ ] padding
    • [ ] field-wrapper
    • [ ] panels
    • [ ] tables
    • [ ] sidebars
  • [ ] margin
    • [ ] panels
    • [ ] tables
    • [ ] sidebars
  • [ ] border-radius
    • [ ] tables
    • [ ] panels
    • [ ] sidebars
    • [ ] buttons
    • [ ] tab group selectors
  • [ ] shadows

Nice to have

• [ ] user-based theming switch. Admins see one theme and users a different one
• [ ] live theme switching. The user could have a drop-down with the current available themes.

Things to consider

• it would be considerably easier to have the same primary/secondary colors on both light and dark mode.

Resources

• https://www.fast.design/ (wayback version)
• https://uxplanet.org/alternatives-to-using-pure-black-000000-for-text-and-backgrounds-54ef0e733cdb
• https://fluxui.dev/themes
• https://ui.shadcn.com/themes
• https://daisyui.com/theme-generator/

[github-actions[bot]]

This issue has been marked as stale because there was no activity for the last 60 days

[github-actions[bot]]

This issue has been marked as stale because there was no activity for the last 60 days

[brandonzylstra]

it's getting marked as stale even though its exempt 😅

[MrJoy]

We've discussed this before, but I'll reiterate here to avoid letting things get forgotten: It would be useful to have parameters configurable per component type, as well. E.G. "Primary button", "secondary button", "primary background", "sidebar background", etc.

I've managed to work around this with some fairly bonkers CSS selectors -- and I've already seen my assumptions break in a couple places as a result of fighting the tooling.

Handling my use-case may be as simple as adding sufficiently distinctive class names I can key to, and avoiding the use of !important so I can more readily override things. Then you can have the general configurability you specify above, while allowing the nitpicky like me to do what we want in a relatively durable way.