Modernize color palette picker and better surface color personalization

[richtabor]

What problem does this address?

The color palette picker UI could use some cleaning up, and after auditing color interactions in Global Styles - I suspect there's a clever way to encourage color palette personalization/creation in-context, instead of requiring people to navigate away from editing towards Global Styles.

What is your proposed solution?

Modernizing the color palette picker UI:

Overall improving the layout of the component by shrinking the footprint, so that color select items do not leave empty space — but rather fill to the container. Also suggesting a tweak to the hover/active/focus state, to simplify those/introduce less weight to selection experience (but maintain visibility; perhaps improve).

CleanShot.2022-07-08.at.12.44.05.mp4

Better surfacing color personalization

Here's a rudimentary mockup of how this could work perhaps. If we lean into this model, we'll want to prototype how deleting would work, and how applying one-off colors would differ from selecting/editing any existing theme/custom colors.

CleanShot.2022-07-08.at.12.52.56.mp4

Notes

1. I realize the Solid | Gradient toggle select is not in my prototype; that doesn't change the idea.
2. This idea considers that there may not need to be a distinction between theme and custom colors — they could be "Site" colors. Technically speaking the distinction is fine (just as technically a theme's template parts and a user's templates parts are different), but experience wise I question if its necessary/useful. I explored this initially when auditing the Global Styles color edit flow here: https://github.com/WordPress/gutenberg/issues/422743.

Related

• Add a shortcut from colour picker to global styles #41871
• Color popovers: inconsistent styling #41787