Possible Color Subtypes/Metadata

[doesDesign]

High level, fuzzy idea here as I create the token taxonomy for my own design system, informed heavily by WCAG accessibility compliance - I could see a need for more specificity when we say type=color.

Basically given a large color palette, I pull out colors for background surfaces, colors that pass 4.5:1 for text, colors that pass 3:1 for icons and large text, etc.

These WCAG compliant colors are not intended to be used as-is by our end designers and devs, because they need to get mapped to semantic meaning first like ‘text-error’ or whatever.

Here’s how I do it in CSS:

:root {
—color_red-800:(dark red);
—color_red-500:(red);
—color_red-400:(slightly lighter red);
—color_red-200:(light pink);
//etc
}

.lightTheme{
—color_text_red:var(—color_red-800);
—color_icon_red:var(—color_red-500);
—color_text_gray:var(—color_gray-700);
}

.darkTheme{
—text_red:var(—color_red-200);
—icon_red:var(—color_red-400)
—text_gray:var(—color_gray-200);
}

.darkTheme, .lightTheme{
—text_error:var(—color_text_red);
—text_negative:var(—color_text_red);
—text_secondary:var(—color_text_gray);
}

In the example above, the primitive palette is used by design system designers, as are the non-semantic text colors like text-red.

The semantic color aliases (error, negative, secondary) are ultimately what our designers and developers would use directly in Figma and in code.

The problem with my CSS approach here is that three very different types of intention get lumped together. color_text_red and color_text_error appear to belong together, when they’re different.

Maybe there’s an opportunity to do this with the new design tokens spec? Not sure if this would be grouping, or some extra metadata or what. “Palette Colors” vs “Mapped Colors” vs “Usage/Semantic Colors”.

I do worry if we try and put them into groups with these names, we might find that breaks a secondary grouping by brand, theme, or something.

[ilikescience]

I think that this is a good use of grouping, not types. $type is intended to be a guide for the parser/translation tool to interpret the token's value.

With grouping, you might do the following:

{
  "color": {
    "base": {
      "red": {
        "200": {
          "$value": "#ffa6a6",
          "$type": "color"
        }
      }
    },
    "semantic": {
      "text": {
        "red": {
          "$value": "{color.base.red.400}"
        }
      }
    }
  }
}

Which would provide a token like color-semantic-lightTheme-text-red. You can choose whichever names make the most sense to your use case.

[kevinmpowell]

The editors reviewed this, and our spec is unopinionated about naming/grouping of tokens. There's a lot of intentional flexibility provided.

@doesDesign does the example posted by @ilikescience make sense?

[doesDesign]

Hey @kevinmpowell - I think so! This one should probably be closed out.

Perhaps what I’m looking for are general best practices around naming these groups but I agree that they shouldn’t change the spec you are creating. For now I’ll likely do “palette” for my primitive colors, “contextual” or “functional” for the colors mapped to text, icons, etc. and “semantic” for the end usage colors (with maybe a final tier for components).

thanks again for your feedback 🙏🏻