Closed gsimone closed 1 year ago
Hi, I'm aware of this current limitation, it has been mentioned before (#1). At the time I wasn't prepared to change the implementation to allow opacity, since I felt like this defeated the point of using radix colors, however I've since changed my mind. Now I feel it is probably better to be more flexible.
To implement this, I think the CSS variables need to be defined as color channels, and the colors need to be defined using the special <alpha-value>
placeholder. The Tailwind docs show an example of this for hsl, so I would assume that this will work.
There would still be a problem with the effective "double" value that the colors have, though just having one hint would already be extremely useful. Remains the question wether we can have both the intellisense working as intended ( and the opacity, I guess) AND the dark/light behaviour.
I'm going to try something the next few days, see if I can help you come up with something
If you refer to Tailwind's support of CSS vars they tell you to only use the values, like so:
--color-primary: 255 115 179;
then define them in tailwind's config like this:
primary: 'hsl(var(--color-primary) / <alpha-value>)',
I don't see why you can't just export the values instead of the numbers, excluding the A
variants.
Something like:
const match = value.match(/hsl\((\d+),\s*([\d.]+)%,\s*([\d.]+)%\)/);
const toHSLObject = hslStr => {
const [hue, saturation, lightness] = hslStr.match(/\d+/g).map(Number);
return { hue, saturation, lightness };
};
const color = toHSLObject(value);
colorMap[`--${key}`] = `${color.hue}deg ${color.saturation}% ${color.lightness}%`;
//...
themeColor[scale] = `hsl(var(--${colorName}${scale}) / <alpha-value>)`;
Hey, me again!
or
won't work because tw uses css variables to set bg opacity. Honestly no idea how this could be solved though, I think both this and #12 are strictly related to referring to css variables instead of having straight-up strings.