variable colors with <alpha-value> not working with theme function on plugins

[gsmeira]

I'm trying to create a plugin for Tailwind 3.1.8, but when I use variables on colors with the new syntax - rgb(var(--primary) / <alpha-value>) - the color stop working.

I created an example on https://play.tailwindcss.com/2apCJBfHdC

Removing the / <alpha-value> from the color value make things work again.

I'm doing something wrong?

[Kosai106]

Looks like a PR was opened about this in the past but somehow the behaviour isn't working anymore. https://github.com/tailwindlabs/tailwindcss/pull/8652

~Related, it would be nice to be able to overwrite the <alpha-value> when using theme(), which I don't believe is possible currently.~ Looks like that is possible. https://github.com/tailwindlabs/tailwindcss/pull/9008

[Kosai106]

I hate to be the one doing this but is there any updates on this @thecrypticace?

[thecrypticace]

No worries! Sorry for the late reply. We have been thinking this through some but other things took priority for the v3.2 release.

The reason it doesn't work for plugins like this is two fold:

1. addUtilities doesn't do anything fancy like parsing data types. It's basically to put pure CSS into the stylesheet whenever a utility is used (and it can handle variants ofc)
2. matchUtilities does parse data types and it takes a type option that lists all acceptable "types" for a plugin — as well as a list of values. You get the <alpha-value> behavior for "free" when using it and your type list includes color.

For example, this works today: https://play.tailwindcss.com/1a6LIjNR2S?file=config — Except for the DEFAULT case + opacity modifier which I believe is a bug but I'll have to check on that. However, we're also thinking through what we want to work here.

I think that in an ideal world each plugin would take in the opacity and modify the color itself (or we provide a function to do this for you — not sure though). And we could remove this special case for the color type. We're going to try to dedicate some time soon-ish to figuring out how this should work at a high level for plugin authors to see if:

1. The existing matchUtilities API / workaround is what we want; OR
2. If there's a better, more automatic API that we can design and implement.