Assembling a gradient from scratch is also more laborious. Gradients are even more pronounced given there’s no sense of “primary”, “secondary”, not even distinct color names and they can be a lot more decorative (the theme Seedlet is a good example, with gradients that work more as background patterns). Now, if a user is interacting with a pattern that contains an image with a rural landscape and the green color is picked because it matches the tone of the image, that use is not semantic in the sense the user wouldn’t expect it to change if they switch themes. A theme might have added a color palette with just two colors - a green and a black - to define its aesthetics. The heart of the issue is the conflict that arises since colors are not always used semantically but also for individual expression. A theme palette generally aims to define a restricted set of semantic colors for branding. The core palette aims to provide quick access to distinct hues reliably.

This is issue is not about the technical aspects of when to classes, inline styles, variables, etc, are employed but about the user expectations and theme integration.Īt the moment, it’s frustrating as a user that upon switching to a theme that overwrites the default color palette you lose access to the rainbow-color set that comes with core. Colors assigned to a palette are expressed through classes. Core provides a default color palette which can be overwritten by a theme. Color handling in Gutenberg comes in two forms: colors picked from a palette and custom colors.

Light gray rgb flat color ui picker