Replace CSS variables using their real values

[varghesethomase]

I have this problem where the library demands the colors to be passed as hex colour codes and not css variables.

icon={{
            path: google.maps.SymbolPath.CIRCLE,
            fillColor: **token('colors.primary'),**
            strokeColor: **token('colors.primary'),**
            strokeWeight: 0,
            fillOpacity: 1,
            scale: 6,
          }}

And hence using it through token() does not work. I found token(colors.primary) returns var(--color-primary). And I would like to receive some inputs on how to have the css variables replaced with the original hex values. The end output is expected to be

icon={{
            path: google.maps.SymbolPath.CIRCLE,
            fillColor: **#ff0000,**
            strokeColor: **#ff0000,**
            strokeWeight: 0,
            fillOpacity: 1,
            scale: 6,
          }}

when --color-primary: #ff0000 is set on :root. I could not figure out a way to do this, but would appreciate any help.

[varghesethomase]

Some observations I had:
When trying to set semanticTokens in panda config file, the usage of token('<semantic_token>') does not return the actual value. It instead returns the var(token-name). When I try to set a color token in tokens on the contrary, token(<token_name>) returns the actual value.
eg:

tokens: {
        colors: {
          red: { value: '#EE0F0F' },
          green: { value: '#0FEE0F' },
          blue: { value: '#0F0FEE' },
        },
      },
      semanticTokens: {
        colors: {
          primary: {
            value: '#061AB1',
          },
        },
      },

In the above example token('colors.red') returns #EE0F0F. And token('colors.primary') returns var(--colors-primary).

[segunadebayo]

That's right. This is because the value of semantic token depends on the context (light or dark mode).

In this case, pointing to core token (like red) is the best approach.

[varghesethomase]

@segunadebayo thanks for your thoughts. I need both the functionalities.

1. multiple theme
2. use token() to get the actual hex codes corresponding to tokens.
   But this limitation with semantic tokens is now limiting me in reading the value of a dynamic css variable injected through semanticTokens that is made available based on the data-theme attribute I am setting on the html tag. Is there a better approach to doing it?

[astahmer]

I guess one way to do it would be to resolve it at runtime like:

const rawValue = getComputedStyle(element).getPropertyValue("--colors-primary")
console.log(rawValue); // outputs "#061AB1"

depending on your element (and where under which data-theme it belongs), it should return the appropriate raw value no matter the semantic token condition

[sanstream]

This would work for client side rendering, but I think this might not work for server-side rendering (like in Next.js). Take this example of a Next.js page that uses numerical values to calculate the sizings of svg elements:

import { css } from "../../styled-system/css";
import { token } from "../../styled-system/tokens";

function cssValueToPixelNumber (cssValue:string) {
  const potentialNumber = parseFloat(cssValue)
  if (Number.isNaN(potentialNumber)) {
    return 8
  }
  return potentialNumber
}

export default function Home() {
  const baseSize = cssValueToPixelNumber(token('sizes.base'))
  const boxSize =baseSize * 20
  const offset = baseSize * 2
  const canvasSize =  2 * offset + boxSize;
  return (
    <main>
      <h1>Test page</h1>
      <svg viewBox={`0 0 ${canvasSize} ${canvasSize}`}
        width={canvasSize}
        height={canvasSize}>
        <rect
          x={offset}
          y={offset}
          height={boxSize}
          width={boxSize}
          className={css({
            stroke: 'graphics.lineWork',
            strokeWidth: '1px',
            fill: 'none',
          })}
        />
      </svg>
    </main>
  )
}

This illustrates how via a workaround I can extract the value from the coreTokens, but it would be nice if I could extract it from the semantic tokens instead so I could define the offset as spacings.2and boxSize as sizes.20 as a semantic token too.

On the other hand you could argue that dark/light mode might need different sizings too. Like for shadows, because shadows are kinda meaningless in dark mode.

For me this solution works for now.