Virtual Colors vs Mutli-Theme Tokens?

[chuckdries]

Hi,

I'm working on an interface which is mostly monochrome, but the user can change the primary color at runtime. I'm wondering whether the Virtual Color feature is right for this, or whether I should explicitly define the various color themes using Multi-Theme Tokens. So far, virtual colors gives me the benefit of re-using the built in theme color palette out of the box, but has the con that I can't use the colorPalette token in my config theme.

Ideally, I'd like to do something like this in my panda.config.ts

  theme: {
    semanticTokens: {
      colors: {
        text: {
          value: {
            base: "colorPalette.700",
            _osDark: "colorPalette.300",
          },
        },
      }
    }
  }

and set colorPalette on the top element in the app and just use the text token everywhere, but that doesn't appear to work.

Any guidance? I get the feeling that Multi-Theme Tokens is what I actually want, but I can't see a way to reuse the default theme hues with that.

[FranciscoKloganB]

Not quite sure what is the objective but have you considered using var(--color-user-palette-700) directly in semantic tokens instead of referencing color tokens?

On the one hand this approach allows user to define whatever colors they want via input field at runtime. Based on those inputs you can update --color-user-palette-* vars on the fly. On the other hand if the user selects premade themes, then probably the easiest is to just define more conditions (e.g., _pinkfloyd, _pineapple) on the semantic tokens.

Please let me know if you need more help brainstorming or in case I missed the point.

[chuckdries]

That sounds like a promising approach, I'll give it a shot. Thanks!

[caseybaggz]

@segunadebayo or @anubra266 I've noticed this too this week when we started scoping out our themes into their own respective presets (basically just semantic color palettes and conditions). Does this mean that the Virtual Color feature is scoped to the preset a recipe belongs to?

For example:

• preset base (recipes & primitive colors)
• preset theme 1 (semantic tokens)
• preset theme 2 (semantic tokens)

Panda config uses all three in the presets option.

Base/recipes/button is something like:

• uses colorPalette.semantic.token.value
• has variant: palette which sets colorPalette based on semantic token group provided

☝️ Since base no longer registers sem-tokens, Panda has no idea how to connect the virtual color? Maybe?

[storchk]

I am working on a project where we have a configuration similar to the one you described. Our base preset defines primitive tokens, breakpoints, etc. Two additional presets define semantic tokens (Theme 1 and Theme 2).

We have found that one of the two presets must be set for the virtual semantic colors to work.

In our Panda config, we set the base preset and load the respective theme preset asynchronously, depending on a condition we define.

https://panda-css.com/docs/docs/customization/presets#asynchronous-presets

[caseybaggz]

OK, that was it. I think this maybe should be included in the docs and probably a feature improvement since it's not ideal? 🤔

Whatever the "base" theme is - must include the theme prop to set it up (like you mentioned). However, you can't to that to any other theme or else it will break the virtual color (e.g., you'll get mixed theme results - like Theme 1 on buttons and Theme 2 on text).

See our PR fix for details