Core Component: Allow Saving Custom Colors to the Color Palette

[SymbolicallyMe]

The Inspiration:

Gutenburg was created to provide editors a modern editing experience while having the most important and/or more common customizable features available to them to create beautiful work.

Understanding Usability & User Experience:
Features that provide customization functionality should not be limited to a set of predefined elements that a user would more than likely need or want to change. For example, given a platform, framework or boilerplate (a base or starting point), a user should have the ability to manipulate or add content where it meets their needs.

The Issue:

The editor has no way of adding and saving custom colors to the existing color palette to be reusable later. Being able to create a palette of custom colors that are available on each instance of editing a post, page, etc. is essential to a speedy creation of a unique theme or brand.

The current color palette is simple and straight to the point, but given that it provides the editor a way to colorize components, it should not limit his/her ability to do so efficiently. The current way to apply custom colors to components will be tedious and repetitive when dealing with subsequent content updates.

The Solution:

The editor should be allowed to add and remove colors on demand, where picking a color in the color picker adds a new color item and automatically saves it a few seconds later or during an autosave.

Since the current colors are using names, allowing the editor to add names to custom colors would also be a good addition, although that would require more UI work.

Custom colors can possibly be saved:

• as a option in the database (will be transferable when migrating a site)
• or, as a static JSON file within the plugin (will be static, but would be lost upon plugin reinstallation)

If this solution is possible or if there is any alternative, I will be happy to submit a pull request.

Conclusion:

Although it is understandable that components of Gutenburg don't actually save meta data in any way, and only perform front-end operations on blocks and post content, this type of core feature would be used by many and would be one less reason to use a CSS stylesheet.

[HardeepAsrani]

Another way is to save it as user meta instead, to make sure every user can add their colors. Not sure how great that solution is, but just thinking out loud. :)

[ZebulanStanphill]

Divi recently made some improvements to their color picker. Thought I would mention it here for inspiration:

https://www.elegantthemes.com/blog/theme-releases/divi-feature-update-the-new-divi-color-manager

[gziolo]

@jorgefilipecosta - something that you may want to comment on.

[jorgefilipecosta]

Hi, @SymbolicallyMe thank you for this proposal and for all the effort on detailing it.
The idea of our color pallet is that it provides color for which we have predefined styles so we can avoid the use of inline styles. If we provide a UI for the user to configure this colors, probably we should also auto-generate classes for this colors and provide a more advanced UI that allows the user to change them if they want.

It also raises some question if the user changes the color on theme A, and then switches to theme B what colors are shown the new colors set by theme B or the colors set by the user on theme A? Are user configured colors specific to a theme or general colors? What if theme B does not allow custom colors besides the ones set by the theme itself and the user previously configured different colors? Are colors specific to each user or each when one user changes the colors the change applies to other users?

I feel as we allow plugins and theme change the color palette they can already use the API's to change colors or even enable the user to replace them and implement a UI identical to what was detailed here.

I think this feature would be nice to have in the future, but I don't think it is a blocker for 5.0, and we may even get some insights about how to answer some questions after knowing what usages the community finds for color API's in the plugins/themes they create.

[SymbolicallyMe]

@jorgefilipecosta I agree that the color classes addition in 2.8 is an easy and simple approach and possibly a sustainable way to add to the color palette from a plugin and theme developer's perspective. A plugin could offer unlimited solutions to how colors are controlled universally or even when switching themes. So, universal colors would be the same no matter which theme is activated.

The API currently provided should give developer's the flexibility they need to control colors, so a color palette management panel within Gutenberg might not be necessary. But, if one did exist, it would provide a consistent way to alter colors on the front-end out of the box for basic color control.

[timelsass]

I strongly agree that resolving this issue would be a great addition to help bridge the gap that exists between having useful color management in themes using the customizer vs overriding all those global settings using the WordPress editor on an instance by instance basis. Many themes provide color options, and eventually as a site becomes more and more filled with content, users begin editing that content with the editor, and things like a style guide slowly become lost as a lot of users publishing or creating content in the editor aren't always design savvy.

By creating a system that can easily translate it's palette to global settings that could be applied easily in the customizer, Gutenberg would be setting the precedent for how themes should implement colors. Allowing users to add colors to their palette via the editor, the publishing platform would be helping those who aren't as design savvy by creating a palette that can be referenced by others easily in the future. "Hey, I noticed you added a new color to the palette when you wrote this article because it's showing up in our palette, let's fix that." The end result would be that users could still have hundreds of colors on their site, but at least they are aware because the colors are present at a glance. Allowing themes to disable the custom color picker right now - it does temporarily fix the issue from a designer's perspective, but from a new user/novice who wants to add and change colors creating this system would be the answer.

@jorgefilipecosta You did bring up interesting points:

probably we should also auto-generate classes for this colors.

I don't see why this is being left to theme developers in the current state since the theme developers are already passing in the colors, and slugs, and the class names are already being forced to follow a certain format, so it seems logical that the css should be autogenerated to save theme developers the extra step of creating this manually.

What if theme B does not allow custom colors besides the ones set by the theme itself and the user previously configured different colors?

I think if color management was handled in the way described where users can add a color, and the CSS is generated automatically that there would no longer be a need to allow theme authors to disable allowing users to add specific colors. The main reason why disabling custom colors is desirable is to prevent inline style colors from not being overridden by global color changes (ie changes usually done in customizer).

Do colors belong to theme A or B?

I don't know, but I don't think it should be user based. Currently the same issue still exists though? If a theme sets a palette for users and defines 5 colors and adds it's own CSS, and the users create content using Gutenberg - their color customization for all their content is going to go missing when they switch themes unless it just so happens that the new theme happens to declare the same colors. So the colors belong to Theme A in this case. If this is what's acceptable then that's that - if the editor is aiming to be more wysiwyg, then generally preserving colors is done with inlinestyles ie what the color classes were wanting to avoid.

Autogenerating the CSS could possibly help with this. Referencing the post/page on the body classes for ones that have used Gutenberg and made use of custom color classes, and by storing the colors used by the theme - the CSS can still be added by WordPress on the frontend to keep the colors/look in tact after theme switch would at least not ruin someone's content if they are expecting it to look the same.

The approach I've taken when working with this issue before is to ditch names - .has-dark-gray-background-color while it's unique and makes sense, there's also not any way to make this universal or adoptable by all themes. Being more systematic by autogenerating the CSS would resolve a few issues, and something like .has-color-1-background-color {} for the first color in a palette, .has-color-2-background-color{} for the second etc would allow themes that define colors to have a somewhat decent chance at having content styled in a somewhat logical way. The downside to this approach is that it assumes that everyone designing content or themes uses the palette order in a similar way, and it's also not contextually descriptive to a designer inspecting/viewing a page. For the most part though - from theme switch to theme switch between different content authors with different palettes - the results aren't ever horribly bad since the palette colors are meant to work with one another even if the amount of presence in the content isn't what the theme designer had originally depicted.

Not preserving the colors, or at least coming up with a solution for color management between theme switch does seem like a bit of a problem.

[talldan]

I've found a few duplicate/similar issues to this. Consolidating them into this issue.

---

#9633

Suggestion: Add a custom palette to the Gutenberg editor color settings for colors that are often reused. For instance, I always end my posts with a signature "blurb" that is bolded with a specific color from the current color pallet. Another instance, sometimes I set off a block of text with a certain color -- and I always use the same color for that purpose, from the current color pallet. When you improve the Gutenberg color palette, maybe you could have two "Text" and "Background" tabs. And the lower section of either tab could be a custom palette.

---

#13017

Problem
When setting text and background colors on a block, a common use case is to use the same color or set of colors for each block.

For example, a company may have a specific color scheme they wish to stick to, and it would be useful to have their colors available in the color picker instead of needing to select it as a custom color each time (which gets tedious.)

The theme sets the colors listed in the color settings, but perhaps this power should be given to the user via the interface.

Potential Solution
A solution would be to see the most-used colors populate in a paragraph block's color settings, or to have the option to set 'favorite' colors.

Alternatives
Alternatives to use include:

1. using the duplicate block feature, so you can set the custom color on your first block and then duplicate that block to copy over the color settings.
2. there may be a plugin option for this. However, it would be nice to have favorite/most-used colors available in the block color settings without a plugin.

---

#20295

I think Color feature in gutenberg is better and better. But I want a feature 'saving color' or 'color bookmark'. I have my signiture color in blog. But It is bothersome to type color each time...

[gziolo]

@talldan and @jorgefilipecosta – it makes me wonder whether the proposal from @youknowriad https://make.wordpress.org/core/2020/01/23/controlling-the-block-editor/ and filed under #20588 doesn't share the same characteristics. In general, it also overlaps with the Global Styles project (https://github.com/WordPress/gutenberg/projects/40).

I also found #15440 with the proposal to pair background and text colors as a predefined set of options provided by the theme author.

Besides, I closed #14110 which is very related to this issue and is going to be addressed in #20588.

[paaljoachim]

Adding in this issue as well:
Documentation: How to specify defaults for text colors separate from background colors?
#28146

[paaljoachim]

@ItsJonQ I think you might want to know about this issue.

[skorasaurus]

Is this something still envisioned with the introduction of a custom palette through theme.json file ?

[jorgefilipecosta]

I think this issue is now fixed. Using the site editor/global styles a user can change the color palette. Thank you all for the inputs!

[paaljoachim]

Hey @jorgefilipecosta

I noticed this comment: #28146 (comment)
"#6941 was closed due to the introduction of theme.json, which does not address different palettes for background vs text.

I have been digging into the button block code for a few hours now to figure out if it is in any way possible to alter or remove the background color palette while leaving the text color palette alone, and I'm just not seeing a viable path. Maybe I'm missing something obvious, but I don't think this is about documentation, and I don't think this issue should be closed."

Should the issue be reopened?

[jorgefilipecosta]

Hi @paaljoachim,

The issue refers "Allow Saving Custom Colors to the Color Palette", and now users can save a custom color palette. It is not possible to have differences on that background and text color palettes, I guess for that we can have a different issue.

[jorgefilipecosta]

Hi @paaljoachim,

The issue refers "Allow Saving Custom Colors to the Color Palette", and now users can save a custom color palette. It is not possible to have differences on that background and text color palettes, I guess for that we can have a different issue.

[paaljoachim]

Hey @jorgefilipecosta and @cr0ybot

I made this issue:
Allow Saving Custom Colors to the unique Color Palette for color og background (Might need to be renamed)
#34445