[v4] Improve the usage of CSS variables for dark/light mode #15083

IonianPlayboy · 2024-11-22T09:41:55Z

IonianPlayboy
Nov 22, 2024

Hello everyone, congratulations to the team for the launch of the v4 beta ! It's very exciting, and it looks amazing.

I have started playing with the new version with the 100% CSS config, and the only thing that did not convince so far is setting up dark/light mode colors with CSS variables.

Note

I am only talking about dark/light mode to keep this simple, but this could apply to any number of theme configured in your main CSS file.

The problem

`dark` variant usage

It's very easy to declare a custom dark variant to customize dark mode detection, as showed in the beta docs :

@variant dark (&:where(.dark, .dark *)); /* <body class="dark"> */ 
@variant dark (&:where([data-theme="dark"], [data-theme="dark"] *); /* <body data-theme="dark"> */

You can then use the dark variant anywhere in your app, and it will work just fine.

Even if at some point you need to change your dark mode detection strategy, or you create a lib that is consumed by other projects with a different dark mode logic, you just need to update/set one line of CSS to have all your app updated.

CSS variables usage

This is sadly not the case if you are working with CSS variables, instead of relying on the dark variant.

Your config would most likely look like something like this (see #14091 & #14095) :

:root {
  --text-fg: #000; 

  :where(.dark) {
    --text-fg: #fff;
  }
}

/* `inline` is necessary to make it work */
@theme inline {
  --color-fg: var(--text-fg);
}

On a local/personal project, this will work exactly like using the dark variant, and it is still pretty easy to change the detection logic by updating only one line of CSS.

However, this is much more problematic if you are publishing a lib. Your users can't override your dark mode detection logic without rewriting all the dark mode values themselves or with a hacky way to change the css file you provide.

Compared to v3

If I am being 100% honest, working with CSS variables in dark mode was not that much easier in v3. The main difference I see is that since v3 is based on a JS config file, libraries would most of the time read the darkModeconfig option to generate their colors in a way that would be compatible with the user's dark mode detection.

Since in v4 the JS config is optional, it is not a reliable technique anymore, and I don't see an alternative solution to solve this issue without forcing libraries to create their own, self-maintained custom config in JS to handle this.

Proposed solution

In my opinion, this is a pain point that is going to be encountered by a lot of users, since CSS variables for dark/light mode are very common when using design systems with design tokens. I find it worthwhile to improve the UX out of the box for this setup, and I believe that you should be able to stay 100% in your main CSS file to configure your dark mode to stay in the spirit of v4.

A potential solution could look like this :

/* Step 1: define your `dark` mode variant */
@variant dark (&:where(.dark, .dark *)); 

/* Step 2: define your color values, independently from the detection logic */
@variations {
  --text-fg: #000; /* this would be the default value */

  @dark {
    --text-fg: #fff; /* this would be the value when the dark mode variant selector matches the element */
  }
}

/* Step 3: define your theme colors as usual */
@theme inline {
  --color-fg: var(--text-fg);
}

This would compile to the same CSS as the example above, but the mode detection should be overridable by users of the lib by simply overriding the dark mode variant definition in their own CSS.

Now obviously this is most likely not the best syntax possible, but I think that the mental model of separating your color definitions from the theme/mode detection is sound.

minht11 · 2024-11-22T23:10:52Z

minht11
Nov 22, 2024

If you are supporting only relative newish browsers you can use light-dark css function.

--color-primary: light-dark(red, magenta);

and the only thing you need to change is color-scheme for colors to change. I am prototyping with this and this cleaned up a lot of code.

1 reply

IonianPlayboy Nov 23, 2024
Author

That's definitely a nicer way to work with CSS variables. If you are starting a new project in V4 where you have full ownership on the theme management, I think that's the best approach. Do you have any codebases where you mix this approach with the darkvariant ? I wonder how easy it would be to make them coexist in the same project.

I would love an alternative baked into Tailwind to support other dark mode detection strategies, and to let librairies detect the user's config. Otherwise you would be out of luck if you are using light-dark everywhere but your component library is expecting a .darkclass or a data attribute to toggle the dark/light mode. It sadly does not help if you want to support more than one theme too.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[v4] Improve the usage of CSS variables for dark/light mode #15083

{{title}}

Replies: 1 comment 1 reply

{{title}}

{{title}}

Select a reply

[v4] Improve the usage of CSS variables for dark/light mode #15083

IonianPlayboy Nov 22, 2024

The problem

dark variant usage

CSS variables usage

Compared to v3

Proposed solution

Replies: 1 comment · 1 reply

minht11 Nov 22, 2024

IonianPlayboy Nov 23, 2024 Author

IonianPlayboy
Nov 22, 2024

`dark` variant usage

Replies: 1 comment 1 reply

minht11
Nov 22, 2024

IonianPlayboy Nov 23, 2024
Author