Dark mode using semantic colors

[nareshbhatia]

I am trying to implement dark mode using semantic color tokens instead of the dark variant provided by tailwind. Wanted to run my approach by this group to see if it makes sense directionally.

Context

This approach was outlined by the Figma team in their Config 2022 presentation titled The hardest part about building dark mode is that people think it’s easy. The basic concept is to use a single semantic token to represent a color instead two atomic tokens, one for light mode and another for dark mode. For example, a single semantic token called bg-brand instead of two atomic tokens bg-blue-800 & dark:bg-blue-600. The supposed advantage of such a system is that it can scale to large teams by reducing the chance of picking inconsistent colors.

Here's an example of how I have been able to simplify my Hero banner which should show a different shade of blue in light vs. dark mode:

<!-- Before --->
<div className="bg-primary-800 dark:bg-primary-600 text-white flex flex-col items-center py-16">
  ...
</div>

<!-- After --->
<div className="bg-brand text-onbrand flex flex-col items-center py-16">
  ...
</div

Implementation Approach

My basic implementation approach is to introduce the semantic tokens as custom utility classes in my global CSS. For example,

@layer utilities {
  .bg-default {
    background-color: theme(colors.white);
  }
  .dark .bg-default {
    background-color: theme(colors.neutral.900);
  }

  .text-default {
    color: theme(colors.black);
  }
  .dark .text-default {
    color: theme(colors.white);
  }

  .bg-brand {
    background-color: theme(colors.primary.800);
  }
  .dark .bg-brand {
    background-color: theme(colors.primary.600);
  }

  .bg-brand-hover {
    background-color: theme(colors.primary.700);
  }

  .text-onbrand {
    color: theme(colors.white);
  }

  .bg-brand-secondary {
    background-color: theme(colors.primary.100);
  }

  .bg-brand-secondary-hover {
    background-color: theme(colors.primary.200);
  }

  .text-onbrand-secondary {
    color: theme(colors.primary.700);
  }

  .bg-default-hover {
    background-color: theme(colors.neutral.900 / 5%);
  }
  .dark .bg-default-hover {
    background-color: theme(colors.white / 5%);
  }
}

For the most part this is working well. I have run into only one snag so far - I don't know how to implement focus ring colors (e.g. focus:ring-primary-500) because these are implemented using CSS variables and not as straight class selectors. Would appreciate any ideas from this group.

Question

What do you think about the overall approach? Can you suggest any improvements or a different approach?

P.S. The full source code of my POC is available here: https://github.com/nareshbhatia/tailwindcss-dark-mode-semantic-colors

[wongjn]

You should still be able to make ring colors like you have already done, like:

@layer utilities {
  .ring-brand {
    --tw-ring-color: theme(colors.primary.800);
  }
  .dark .ring-brand {
    --tw-ring-color: theme(colors.primary.600);
  }
}

And then in HTML:

<button class="focus:ring focus:ring-brand">

[nareshbhatia]

Didn't realize it's going to be that simple!! Thank you so much @wongjn.

[adamwathan]

I would define all of my colors as CSS variables and use a parent selector just to change the values of the variables, no need to create tons of custom classes:

https://tailwindcss.com/docs/customizing-colors#using-css-variables

This demo is several versions behind so some things are out of date but should communicate the idea clearly at least:

https://github.com/adamwathan/theming-tailwind-demo

Personally I think doing dark mode this way is seductive but not as practical as you expect. Tons of situations where you end up swapping the same color in light mode for two different colors in dark mode depending on how it’s used, and then you need to come up with different names for those two colors and it quickly becomes a very big project.

[nareshbhatia]

Thanks for your insights, @adamwathan. I can see how coming up with semantic names for colors could become extremely difficult for more complex projects.

Going back to the dark variant approach, do you have any tips for ensuring consistent use of colors across a large team? I can see two people accidentally using a different variation of brand color on a button vs. a drop down.

[BTW, your theming example certainly looks simpler than my approach! Will give it a try.]

[nareshbhatia]

@adamwathan, another followup question. The typography plugin seems to use semantic naming of colors with invert variations for dark mode. How does it work internally? Any similarities with the dark variant approach?

[nareshbhatia]

I implemented the theming approach suggested by @adamwathan. Everything works well except for one thing - the MoonIcon is not showing up in the dark mode (the SunIcon is shown instead). Here's the relevant code:

<SunIcon className="h-5 w-5 stroke-default dark:hidden" />
<MoonIcon className="hidden h-5 w-5 stroke-default dark:block" />

Note that I am changing by theme by adding one of two selectors to the <html> element: theme-light or
theme-dark. To make the dark variant work, I have added the following to my tailwind configuration:

darkMode: ['class', 'theme-dark'],

What am I missing?

Full source is here.

[adamwathan]

I think you need to add a dot before the class name here:

darkMode: [‘class’, ‘.theme-dark’]

On my phone or would test properly but give that a go.

[nareshbhatia]

Works like a charm! You are the best @adamwathan 😊