feat: Ability to use relative color syntax in the theme file about ionic-framework

[oliviawongnyc]

Hi, @liamdebeasi, this makes sense. Thank you so much for looking into it, and for your super thoughtful explanation!

[liamdebeasi]

Thanks for the feature request. This is a really cool idea! The team did some discovery into this last week, and unfortunately we won't be able to support this at the moment. The original reason why we have separate hex and rgb values is noted on our docs.

In an ideal world we'd be able to use the relative color syntax that you mentioned and be able to have a single set of hex color tokens. Unfortunately, Firefox does not support the relative color syntax, so supporting this would not work there. Chrome, Edge, and Safari support it, but there are several older versions of these browsers that Ionic still supports.

We considered a couple alternatives:

1. Only have tokens for the RGB values
   This would mean you'd only have something like --ion-text-color-white: 255, 255, 255. This would let us have a single set of tokens that would also you control the alpha. You'd need to do the following to use it:

:root {
  --ion-text-color-white: 255, 255, 255;
}

.foo {
  color: rgb(var(--ion-text-color-white) 0.5);
}

We didn't like this approach for a couple reasons:
a. Your IDE wouldn't show you the color since the value of the variable isn't actually a valid color. In the context of the rgb function it is, but your IDE doesn't know that's the only way it will be used.

b. The usage would be more involved than it is now since you would need to always use the rgb function instead of just passing the value to the color property.:

:root {
-  --ion-text-color-white: #ffffff;
+  --ion-text-color-white: 255, 255, 255;
}

.foo {
-  color: var(--ion-text-color-white);
+  color: rgb(var(--ion-text-color-white));
}

2. Support the relative color syntax with a fallback
   This work would involve conditionally applying the relative syntax based on browser support. We ultimately decided not to go this route because it would have added a decent amount of technical debt for the team to maintain. It also could be confusing for developers because there would potentially be 2 different API usages based on browser support.

---

I think it's worth looking into again once browser support improves. I am going to close this, but let me know if you have any questions.