Clay: Clay: Replace color values

[drakonux]

Proposal

Change the current values of the following colors in Clay with the secondary colors defined by Lexicon:

$blue: #0B5FFF ----------> #4B9BFF
$indigo: #6610F2 -------> #6610F2
$purple: #6F42C1 -------> #AF78FF
$pink: #E83E8C ---------> #FF73C3
$red: #DA1414-----------> #FF5F5F
$orange: #B95000 ------> #FFB46E
$yellow: #FFC107 --------> #FFD76E
$green: #287D3D --------> #9BE169
$teal: #20C997 ----------> #50D2A0
$cyan: #17A2B8 ---------> #5FC8FF

Benefits

Clay would be aligned totally with the current color definition.

[pat270]

Changing the color values outright would be a breaking change. I think we can work something out where we can have both.

[drakonux]

Ei @pat270 could you explain to me more details of why this would be this a breaking change? (maybe it's a silly question sorry 🙏)

What options do we have?

From my point of view, Clay should be as close as possible with the definition made by Lexicon. So, keeping the default value for those Bootstrap colors it's not what we would like to provide to product teams.

[pat270]

@drakonux I like keeping the color values consistent with Lexicon, but unfortunately we already released several versions with the current colors. Changing $blue: #05BFFF to $blue: #4B9BFF would change the color of any item using the variable $blue, for example:

.my-custom-btn {
  background-color: $blue;
}

.my-custom-btn's background color would change from #0B5FFF to #4B9FFF.

We would also break the default color of Bootstrap's gradient-x-three-colors and gradient-y-three-colors mixins, granted I don't think many people know about it.

I only have two options right now:

1) Add a setting like $enable-lexicon-chart-colors: true (that's what it's labelled as on liferay.design) that lets the changes be easily reverted if it breaks their stuff.

2) Add new variables $stark, $mormont, $lannister, $martell, $tyrell, etc. I don't like this idea too much since there's a learning curve to match colors to the names and hard to remember spelling. Maybe we can do something like $blue-l1?

If you have any other ideas I'm open to hearing them.

[jbalsas]

Hey @pat270, I'd say we can go with 1 and have the colors overridden by default in 3.x with the flag set to true and to false in 2.x so we don't change anything.

We still haven't integrated css 3.x in themes, so we still have some leeway here, and we can later override the flag in styled before passing it down to other themes whenever we start using [email protected]

[marcoscv-work]

The change should be done only in atlas, in that case, I cannot imagine someone using original BS colors under Atlas theme.
I think the most important technical reason to overwrite those variables would be the intention to use CSS4 variables as for example Echo team wants to use

[jbalsas]

Changing it in atlas makes more sense, indeed! 👍