Shadow tokens that use a rgba() output colors as rgba(#hex, ..)

[six7]

It seems that shadow tokens that use a rgba() value won't transform the used value inside the rgba() function. That means if my tokens reference a hex value, we don't currently change that hex value to the required rgba() equivalent.

{
    "base": {
        "value": "#fff",
        "type": "color"
    },
        "rgb": {
        "value": "rgb(0, 0, 0)",
        "type": "color"
    },
    "shadow": {
        "type": "boxShadow",
        "value": [
            {
                "x": "0",
                "y": "1px",
                "blur": "1px",
                "spread": "0",
                "color": "rgba({rgb}, 0.15)",
                "type": "dropShadow"
            },
            {
                "x": "0",
                "y": "2px",
                "blur": "0",
                "spread": "0",
                "color": "rgba({base}, 0.15)",
                "type": "innerShadow"
            }
        ]
    }
}

Actual output

--sdShadow: 0 1px 1px 0 rgba(rgb(0, 0, 0), 0.15), 0 2px 0 0 rgba(#fff, 0.15);

Expected output

--sdShadow: 0 1px 1px 0 rgba(0, 0, 0, 0.15), 0 2px 0 0 rgba(255, 255, 255, 0.15);

Configurator link

https://configurator.tokens.studio/#project=rVPdbsIgFH6Vht2oYVWX7MYX2O2SXVqz0ALK1kED1Gmavvs4pazFTecSG0I45/vO3wdtUKEkF9v0zSiJVqjJZJJkyKhaFyxDq2QNDnDNZvNZatU7k6YjZwiQDfYBVUksV/rDQEwTYgoztsFjNZEGiE9a1RWAztclvTe2pkJlCA/sSjMuDp5laATltSjpM7E7j3bm3NWbRywuSmZGY8DXDEegUGaskMQKGAlSve6JFiR3gWnXP4750Dyxngr1vtleEP+14bjxh852W4sw8nOOpQy6d3MRwyLNwLknZc18yTvOedST0+9Y9WChSqVDH21E0tv8UloHTxY4gTX9X3p3MztC1eeP7ENcrg4vPQf/Wn89lvjkhgK5fwaLkwsJ8NHDy+pwhpCXtf6LY9yDI/RyoV6EXjQyadzeOtnS5eP0TMigBNWqClLEzBbfTIOHKzRY3FIBeLNXSyCkZPqMBoM5/DduofYL

[jorenbroekema]

From 0.12.1 part of this issue has been resolved, namely that the rgba(#fff, 0.15) wthin a larger token is not resolved correctly.
Now, it is :)

However, the other part of the issue remains, which is that rgba(rgb(0,0,0), 0.15) is not resolved to rgba(0,0,0, 0.15).
Similarly, this occurs with other color formats as well when they are being cross referenced from one format to another, e.g. rgba(hsl(255, 0, 255), 0.15) should theoretically be resolvable.

I think it makes sense to solve at least rgb(a) within rgb(a) and resolve this ticket:

• rgba inside rgba
• rgb inside rgba
• rgb inside rgb
• will not solve rgba insde rgb since this is invalid, as the alpha value would be lost. I suppose we could make an exception if the alpha is 1 though

Then at least when people are being consistent in using rgb(a) format, they can use them in a nested way with references. I think that covers most people's use cases.

We can create a separate enhancement issue for:

• other examples of the same format within the same format e.g. hsla(hsl(), 0.15) and similar, this may be somewhat straightforward if we have the code that does this for rgb(a) already.
• using different formats within different formats e.g. rgba(hsl(255, 100, 50), 0.15), but I suspect the implementation of this could get pretty complex and maybe there isn't any demand for this niche use case.

But I only think that really makes sense if other formats are accepted in the figma plugin, if not, we don't need to get into it I think.

[yoerivdm]

Just ran into the same issue, apparantly the niche case :-)
Added a transform of my own to solve it ...

sd.registerTransform({
  name: 'hslToRgb',
  type: 'value',
  transitive: true,
  filter: token => {
    const type = token.$type ?? token.type;
    return typeof type === 'string' && ['color', 'shadow', 'border'].includes(type);
  },
  transform: token => {
    const val = token.$value ?? token.value;
    const type = token.$type ?? token.type;
    if (val === undefined) return undefined;

    if(val.includes("rgba") && val.includes("hsl")) {
      var regex = /rgba\(\s*hsl\(\s*(?<hue>\d*(\.\d*)*), \s*(?<saturation>\d*(\.\d*)*)%\s*\,\s*(?<l>\d*(\.\d*)*)%\s*\)\s*,\s*(?<alpha>\d*(\.\d*|%)*)\s*\)/g
      const HSLToRGB = (h, s, l) => {
        s /= 100;
        l /= 100;
        const k = (n) => (n + h / 30) % 12;
        const a = s * Math.min(l, 1 - l);
        const f = (n) =>
          l - a * Math.max(-1, Math.min(k(n) - 3, Math.min(9 - k(n), 1)));
        return [255 * f(0), 255 * f(8), 255 * f(4)];
      };
      return val.replace(regex, (match, hue, _c1, saturation, _c2, lightness, _c3, alpha) => {
        try {
          var [r,g,b] = HSLToRGB(hue, saturation, lightness);
          return `rgba(${Math.round(r)}, ${Math.round(g)}, ${Math.round(b)}, ${alpha})`

        } catch (e) {
          console.warn(e);
          return match;
        }
      });
    }

    return val;
  }
});

[jorenbroekema]

Yeah I saw someone ran into this because they were using color modifiers and formatting those to HSL, but then those colors are referenced in other tokens that are using Figma's rgba(hex, alpha) format, so basically:

{
  "colors": {
    "foo": { 
      "value": "#f00",
      "type": "color",
      "$extensions": {
        "studio.tokens": {
          "modify": {
            "value": "0.5",
            "type": "lighten",
            "space": "hsl"
          }
        }
      }
    },
    "ref": { 
      "value": "rgba({colors.foo}, 0.5)",
      "type": "color"
    }
  }
}

A fix in that use case could be to just add "format": "hex" to the token's modify object or add it globally:

import { register } from '@tokens-studio/sd-transforms';
register(StyleDictionary, {
  'ts/color/modifiers': {
    format: 'hex',
  },
});

But besides these workarounds, I can still imagine cases might occur where it's still an issue and this issue is still worth fixing at some point with a custom transform in this sd-transforms package that normalizes all that stuff.

Playground example