Proposal: Rethink Tailwind Dark Mode Strategy #951
Replies: 1 comment 1 reply
-
|
What the challenges / issues with Proposal 1? It sounds straightforward to me. 😁
It's only one or the other, depending on the mode, right? |
Beta Was this translation helpful? Give feedback.
-
|
Ideally we support BOTH. Which affects dozens of Skeleton provided styles. It's not a small lift sadly. But this is the kind of information we're taking into account for our "Next" iteration discussed here: In this post I call out "building Skeleton today with all current knowledge", this is the kind of thing I'm referring to. We really need Skeleton built from the ground up to support this. So progress is happening and coming soon:tm: |
Beta Was this translation helpful? Give feedback.
-
So after a back and forth discussion with @AdrianGonz97 and @ryceg today, we've identified a fairly major flaw in how we utilize styles in Skeleton. Specifically when it comes to our dark mode strategy.
Here's Tailwind's docs on the subject:
https://tailwindcss.com/docs/dark-mode
What this means is you have two strategies available to you, based on the
tailwind.config.cjs:darkMode: "media"(default) - sets dark mode based on the OS preference using prefers-color-scheme media queriesdarkMode: "class"- applies dark mode when a.darkclass applied the<html>elementCurrently we support the second option - the class-based approach, as we assumed early on that most folks will want to manually set/toggle the theme based on the user's preference, rather than OS preference. This seems to have panned out. Most folks use this and we've had only 1-2 requests for the OS preference option.
The Issue
The problem we're facing is that our current approach for generating design tokens and utilizing CSS stylesheets with @apply actually prevents the
mediaOS preference option from being a viable option using only Tailwind. In a sense we're generating the light/dark iteration of these classes in a very static manner. With most dark iterations generated via.dark .foo. This works great for the "class" mode, but does not work in the OS prefer "media" mode.Long story short, the
mediaoption is NOT currently available to use in Skeleton. It simply does not work.Short Term Solution
For now, the good news is we can still support the the OS-preference option WITH
darkMode: class. But it involves extra JS to listen to thewindow.matchMedia"change" event and toggle the.darkclass on the<html>element. This is not a bad solution. Heck, even Tailwind themselves use this on their doc site.In fact this is really the only solution to support both class + media options at once, per:
https://tailwindcss.com/docs/dark-mode#supporting-system-preference-and-manual-selection
So I think what we do is factor this into our planned updates to the Light Switch component/service, per:
Long Term Solutions
Proposal 1
If we wished to continue using this approach with the rigid/canned classes, then we would essentially have to maintain THREE sets of all our design token classes:
.foo {}.dark foo {}@media (prefers-color-scheme: dark) { .foo {} }<--- add thisThis is already very tedious to maintain, and adding a third options only worsens things. I'm also not positive this third option is even possible in CSS-in-JS format, making it DOA for us. Therefore I highly suggest we avoid this as anything other than an temporary solution.
Proposal 2
Plain and simple, Tailwind doesn't like our approach of building canned styles, be that design tokens or stylesheets using
@apply. So in this proposal everything becomes primitive utility classes. No "combined" classes whatsoever, no generated plugin classes, no stylesheets via@apply. This is much closer to what Flowbite is doing:The issue being of course that a lot of these these combined classes are VERY handy for users. Being able to write
bg-surface-50-900-tokenis much easier thanbg-surface-50 dark:bg-surface-900. It also enables safeguards for coloring pairings (ex: 50-800 instead of 50-900)Proposal 3
We find another way to approach this problem. Perhaps even waiting until Tailwind v4 drops in the future to see what changes they have implemented. Adam has hinted heavily that a lot of config will be moving into CSS, rather than JS-in-CSS as it is now. That change alone may alleviate most of our issues.
Beta Was this translation helpful? Give feedback.
All reactions