…and that’s what we don’t want.

Same here… half aliases and half hard values. Not good.

is there a workaround yet? Or a roadmap that tells when variables v2 will be released?

Would also love to know if we can expect v2 within the end of the year 🙂

Would love this too! In my organisation we would need to reference our Color Primitives and specify the opacity only in the semantic layer. This is currently impossible, I need to create new variables disconnected from the primitive value to achieve this. As it is, this seems to go against the spirit of Variables, would be amazing if this could be added!

This will be very helpful. Hope it gets added soon

+1 Tailwind does this very elegantly:

<p class="text-blue-600/50">The quick brown fox...</p>

You define your fully opaque colours and then make those transparent with the slash. ❤️

Any updates?

+1 would be great to ensure better color consistency across variables. Not to mention changing color palettes and building themes would be so much easier this way

+1 we are missing a way to apply an opacity to an alias variable… when using opacity yuou are required to use hex value instead of alias

I’d use css color-mix(in srgb, var(—brand-100), transparent 50%). Does wonders 😉

Hers is an example Source Foundation / Tailwind CSS

The other, a bit more complex, way would be to perform Brightness / Luminance calculations on the shades of gray for contrast variations. The same way Android Dynamic Colors work.

The general idea is to have a conditional for contrast and pick either shades from white to gray, or from shades of black to gray to hit the target Contrast Ratio. Previous Android versions did this by modifying solid white/black opacity, not sure how they’re doing it right now.

So, calculating Color Variables using basic HSL/HSB and Opacity transformations is one thing, but making decisions (conditionals) on Threshold Brightness / Luminance and Threshold Contrast comparison is yet another thing. Having a set of functions to derive and modify colors is just a start.

This is a feature I’m waiting since 2017.

Comparisons on color contrasts are crucial for proper Accessibility standards adoption - WCAG contrast ratios are a thing.

It’s something 😅

…something almost useless compared to what we asked. We didn’t ask for variables for opacities… we asked for aliased variables with opacity. Who the hell is going to create a variable for each opacity?! Opacity is something that doesn’t make sense to standardize because it strongly depends on the context, so where the color is used… this is useful only someone want to create an opacity variable each 10 steps. Like opacity-0, opacity-10, opacity-20 and so one… useless in 99% of the real use cases.

You can simplify the code by using transparent as starting color so you don’t have to do the calculation:

/* Return a 70% transparent red */

color: color-mix(in oklab, transparent, red 70%)

Also this is basically useless since we can’t set opacity for the shadow color once you set the variable…🤦

Agreeing with @Equinusocio, this does not work for me.

Curious how in the video these variables are accessed. I‘m clicking where the person in the video clicks, but I don‘t get the option to bind it to a variable.

+1 to this! I’ve been struggling with this a lot. The layer workaround in the Tweet is enough for me for now, but directly applying the opacity to a variable referenced by a token would be much better. Hope to see it soon 🙂

Right click on the field. Really subtle. Sometime there is the icon, sometime you have to right click (on textfields). Really bad UI decisions lately.

Oh, I see. I hope this is a temporary solution because variables are in beta, and they‘ll make it more intuitive after the official launch.

You can also shift + left click the field to go straight to the variables, this works on other variable fields too such as border radius, height etc. Not intuitive but a handy shortcut

Replying because I CANNOT believe this is still not possible… How hard is it to implement this much needed feature?

Oversights like this make using variables awkward and lead to bad practice when time is tight.

It’s a similar issue to not being able to just apply “bold” or another formatting override to a text style (especially inside a text block!)

It’s adding blockers to a system that’s meant to make everyone’s job easier.

Having to add a seperate variable for every 10 opacity is working harder, not smarter.