Ability to use Global Color variable with color adjustment

[alexanderkladov]

Describe the feature you'd like to see included in Oxygen. It would be amazing, if we could apply color adjustments to an existing Global Color variable, when using it somewhere on the page. Exactly how you would use adjust-color() in SCSS.

That way we could assign the same Global Color to many UI elements on the page, but those elements could use a different shade of the original color. And if one day we wanted to change the entire website color palette, we could simply change the 1 original Global Color and all of those elements will inherit the change and will have new shades of the new color applied to them automatically.

Right now we have to either create dozens of slight color variants (for hovers, borders, shadows etc) and save them in Global Colors for future use (which quickly gets out of control) or we just have to "hardcode" the colors into the element classes, which is also not ideal.

For now that (and lack of any variables like Global Padding/Margin) is one of the major reasons I have to use WP-SCSS plugin with Oxygen. If both of those were implemented, I probably would've been able to use vanilla Oxygen for pretty much everything.

What are the use cases for this feature? Ability to swap the entire website's color palette by simply changing a small set of Primary/Secondary Global Color variables. Every other element can be configured to use those variables, but with a color-adjustment applied, where necessary, without losing the link to the original color variable.

[Xilonz]

scss/sass/css editor improvements are already suggested here: https://github.com/soflyy/oxygen-bugs-and-features/issues/20

[alexanderkladov]

@Xilonz What I'm suggesting is not related to SCSS/SASS. I am saying that it would be very handy if it was a feature inside all Oxygen Builder color pickers, which would allow use of Global Color variables + any necessary color adjustments.

Like the ability to use a color variant (darken, lighten, add opacity etc) of an existing Global Color inside Oxygen Builder, without actually creating a new local color just for that element. Hope that makes sense. That local color can't be reused again, unless it's saved as a Global Color (and if you have to save every variation of a color in Global Colors, that would make an absolute mess of your color palette picker). Also, even if you save them all as Global Variables and use those, if one day you'll want to change the color palette (which happens pretty often), you will have to change every single Global Color variation too, which can be a lot for every possible version of default/light/dark + hover for each + inverse for each etc. On top of that, do you know if you used a 10% lighter variation or a 20% when creating that Global Color variation? You can't tell, so just have to eyeball it. It's just a mess that way. Those variations should be applied on the class/element level, when using the color, if they are derived from 1 original global color.

How this could be implemented? For example, in Oxygen style configs for a class/element, the colors are referenced as color(ID). What Oxygen could have is an ability to add variations to that same color somehow, which would then be saved as an array like color(ID, "adjustments" => array("lighten" => 10, "opacity" => 0.5)). That way we still use the original color ID + have any number adjustments applied to the color on the fly. And those don't have to be applied via SCSS, they could be handled by PHP (there are plenty of simple, efficient & ready-to-use color adjustment functions out there).

I do love the idea of having SCSS for sure & I currently have some of those color manipulations implemented using SCSS, but it has it's downsides, when it comes to handling colors. For example, that color is not updated in real time inside Oxygen Builder itself. It will only come into effect once the chosen Global Color variable is updated & then the page reloaded, which is not ideal an goes against WYSIWYG. Plus I have to apply those colors to classes/elements outside of the builder interface too and it can be confusing for someone else to figure out where the color is coming from. It's just not an elegant solution and feels like hackery. That should be handled inside the builder IMHO.