Opacity

[platon-ivanov]

Hello, thank you for the plugin, it's the best of both worlds!

Is it planned to add opacity settings similar to hsl-radix-colors? I feel it would bring the color palette even closer to Tailwind.

[yp717]

Thank you for the feedback :) I'm glad you find the plugin useful!

It's not something that we were originally intending to support but I can have a look into this. What would be the use-case / preferred syntax to introduce opacity just to make sure I've understood the request correctly

[platon-ivanov]

I would imagine the syntax to be the same as other Tailwind colors, e. g. text-crimson-500/50 bg-indigo-1000/80.

Since the plugin is using the hsl color space, it should be possible to implement transparency by switching to hsla with the <alpha-color> approach.

Opacity is a generally used feature. Off the top of my mind I'm thinking of semi-transparent modal overlays and other semi-transparent-backgrounds, disabled buttons and certain text and icon effects. Certainly it's possible to achieve transparency with the opacity property in most use-cases with or without using some boilerplate. But adding opacity to colors in the plugin would make it a compromise-free alternative to Tailwind colors while having dark mode built in.

[yp717]

I see what you're saying :)

There are currently both variants in the hsl and hsla color space. This is how the original Radix palette exposes the alpha value and they provide a set of presets.

Allowing users to set the opacity value explicitly (tailwind style) will be more consistent with tailwind's behaviour but deviate somewhat from Radix's original behaviour.

For example with the color amber the package has both amber and amberA available:

  amberLight: {
    100: 'hsl(39, 70.0%, 99.0%)',
    200: 'hsl(40, 100%, 96.5%)',
    300: 'hsl(44, 100%, 91.7%)',
    400: 'hsl(43, 100%, 86.8%)',
    500: 'hsl(42, 100%, 81.8%)',
    600: 'hsl(38, 99.7%, 76.3%)',
    700: 'hsl(36, 86.1%, 67.1%)',
    800: 'hsl(35, 85.2%, 55.1%)',
    900: 'hsl(39, 100%, 57.0%)',
    1000: 'hsl(35, 100%, 55.5%)',
    1100: 'hsl(30, 100%, 34.0%)',
    1200: 'hsl(20, 80.0%, 17.0%)',
  },
  amberLightA: {
    100: 'hsla(40, 94.9%, 38.7%, 0.016)',
    200: 'hsla(40, 100%, 50.3%, 0.071)',
    300: 'hsla(44, 100%, 50.1%, 0.165)',
    400: 'hsla(43, 100%, 50.0%, 0.263)',
    500: 'hsla(42, 100%, 50.0%, 0.365)',
    600: 'hsla(38, 100%, 50.1%, 0.475)',
    700: 'hsla(36, 99.9%, 46.2%, 0.612)',
    800: 'hsla(35, 99.8%, 46.0%, 0.832)',
    900: 'hsla(39, 100%, 50.0%, 0.859)',
    1000: 'hsla(35, 100%, 50.0%, 0.891)',
    1100: 'hsla(29, 100%, 33.6%, 0.980)',
    1200: 'hsla(20, 99.8%, 14.1%, 0.965)',
  },

Also note that the hsl component between amber-1200 and amberA-1200 are not the same. Would the proposal entail:

1. Switching the non alpha palette from hsl to hsla and allowing you to set the alpha value
2. Allowing you to hijack the alpha value of the alpha color set?
3. Something else?

[platon-ivanov]

Before this plugin I have used other ways to add Radix colors to Tailwind, but have never touched the A variants and went other ways instead. I understand that

Each scale has a matching alpha color variant, which is handy for UI components that need to blend into colored backgrounds. (Radix Colors)

However, I'm cautious about this behavior, as it raises concerns about deeply nested elements, where semi-transparent backgrounds can unexpectedly blend into unintended colors. Perhaps I'm mistaken, and if so, I kindly ask you to enlighten me.

While styling a website with Tailwind, I prefer not to be concerned with the underlying configuration, like which color spaces I'm working with, or that I have to add a dark: class any time I use any color, which was my main draw to this plugin.

Tailwind already supports the simple and predictable / syntax, and implementing the transparency with your 1st solution will keep the syntax simple and predictable.

Granted, that creates the issue that then the alpha variants would most likely be expected to support the same behavior. That could be achieved with something like

amberLightA: {
    100: 'hsla(40, 94.9%, 38.7%, calc(0.16 - 0.16 / 100 * <alpha-value>))',
    ...
}

The steps would be pretty unpredictable, since different color levels would have vastly different steps. But it would at least keep the syntax uniform for both variants. That way the Radix palette would be transferred precisely while also conforming with Tailwind standards.