Alias Colour Properties to meaningful scoped component names

[aaronstezycki]

Hi all.

I came across the article about using custom properties for colour definitions/tokens which I found very helpful. Being able to change alpha/saturation whilst still using colours from the global colour palette is handy.

One thing I and team have found the technique falls short on, is being able to alias colour tokens to more defined roles so that naming is less abiguious and more specific. Being able to do the following would make more sense to some of our developers that are learning the code base and the design system.

:root {
  --input-text-color: var(--slate-600); // this works
  --input-ring: var(--blue-600); // this works
  --input-outline: alpha(var(--blue-600)); // this doesnt work.
}

.input {
  color: var(--input-text-color);
  border: var(--input-ring);
  box-shadow: var(--input-outline);
}

This promotes following guidelines set by design systems and not putting in arbitrary colour tokens into components that can be and are often incorrect. So far, I haven't been able to find a way to getting around effectively using alpha/saturation SASS functions mentioned in the article, because SASS doesn't seem to compile the functions when they are written into the custom properties like so ...

:root {
  --input-text-color: alpha(var(--slate-600), 0.5);
}

// Compiles to:
// color: alpha(var(--slate-600), 0.5); 

Is there any way around this?

[sebastiano-guerriero]

Hi, in CodyFrame we use the defineColorHSL mixin to define the color variables:

:root {
  @include defineColorHSL(--color-primary, 220, 90%, 56%);
}

// compiles to 👇
:root {
  --color-primary: hsl(220, 90%, 56%);
  --color-primary-h: 220;
  --color-primary-s: 90%;
  --color-primary-l: 56%;
}

Therefore you could define color alpha variations like that:

:root {
  --input-text-color: var(--slate-600);
  --input-outline: hsla(var(--slate-600-h), var(--slate-600-s), var(--slate-600-l), 0.5);
}

[aaronstezycki]

Ah I see, so unfortunately there's no way to continue using the alpha/saturation functions, and simply you just have to write out what you might expect from the function itself? That's fine, just might be a little confusing for developers not being able use one solution for managing transparency or changes to colour on the fly.

Thanks for your help :)

[aaronstezycki]

@sebastiano-guerriero Just one more question :)

I'm using the same technique/mixin above to build our colour custom properties. i.e :

:root {
  @include defineColorHSL(--color-primary, 220, 90%, 56%);
}

Just wondered what your thoughts were on code bloat and how using this technique might impact the end-user downloading a large set of custom properties. Is the rendering time/download speed of CSS impacted by using custom properties at large or is this a negligible hit for ease of use and maintainability improvements?

I know you could probably offset code bloat with something like CSS Purge, but SASS variables also have the benefit of hard coding in colours and not storing the variables at run-time like custom properties? Just wanted to know your thoughts?

[sebastiano-guerriero]

So far I've never experienced any performance issues related to the CSS custom properties. I don't work on websites with millions of daily users (although I inspected Twitter's code and they use CSS custom properties). There are a few interesting article on the topic ((example)[https://lisilinhart.info/posts/css-variables-performance/}). I'd avoid using varibles that target all elements, something like:

* {
  --variable: 20px;
}

Hope this helps!

[aaronstezycki]

Thanks @sebastiano-guerriero. I've recently too found/inspected multiple websites that use custom properties and in no way a small amount of them. Inspecting Github, they use ~500 custom properties! Thanks for your input.