Variables: Color alias with alpha / opacity (rgba ideally)

Just means you end up having to create loads of primitives that are untethered to the root variables though, bit of a nightmare.

Wouldn’t overcomplicate things honestly, just decouple opacity from variables — as in, let me set the opacity in the individual instance, as I would with any other colour. There are so many circumstances where it makes sense to use a slightly different alpha value depending on the context (e.g. brighter colours like greens and yellows needing lower alpha values) that attempting to systematise it seems like a fools errand.

“Just decoupling opacity from variables” would absolutely break other functionality for design system usage.

I know your intent is to suggest an easy to implement solution, but easy solution for a complex problem will only create more problems elsewhere.

If I (as a heavy user and design system maintainer) got the ability to separately apply opacity on top of a variable (needed sometimes), but lost the ability incorporate opacity into a variable (needed always), I would rather not have the ability to apply opacity separately.

A more complex solution that allows for both is the only way to add value without losing it.

Yeah, sorry, I was just suggesting a way around it for now. But agree support for opacity within variables is still needed for easier maintenance. It could easily become messy otherwise.

I use components to have all kinds of colour adjustments →

Works well for me. This way I can fade, shade and tint any colour I like, make gradients without adding colours to the main palette and have drop shadow with any colour, opacity and blend mode.

Don’t necessarily have to throw the baby out with the bathwater, could maintain the coupling between opacity and variables, use the specified opacity as a default, and have a “lock/unlock” functionality to allow for opacity changes to be made on top of the variable?

I still don’t think it’s practical to define opacities so rigidly because of the intrinsic differences between how colours are rendered on screens, for example if you’re making a set of statusTag components, each with a subtle coloured outline, the alpha values for each would need to be slightly different to maintain perceptual consistency, even if you account for the lightness values in your palette, the perceptual difference between colours is well documented.

On some level maybe it would be worth adding a variable type called “Opacity”? That way you could define a palette of opacities to be applied “on-top” of each of your variables when appropriate?

Practically speaking, this is what we do in our frontend components library, an ::after pseudoelement that overlays a translucent white element to produce a highlight effect, however as we’re growing and have a need to use these resource tokens elsewhere (e.g. making those hover colours available in Javascript, instances where pseudoelements aren’t feasible, etc.) it’s becoming more and more of a necessity to actually have all of the root colours available and tokenised. I’m more concerned with outlines and box-shadows (for focus states, subtle element highlights, etc.) in this instance though unfortunately — great idea though.

Thank you for sharing! Great idea! This workaround will definitely come in handy for small libraries.

However, in larger libraries, it might unfortunately increase the weight of the library and negatively impact its performance.

Yes Please! much needed feature

+1, very useful feature