Components: introducing ColorSwatch and updating existing color-related components

[ciampo]

In the context of working on the Global Styles Sidebar, we're looking to move the prototype over to Gutenberg. One component that is used in the prototype is the g2 ColorCircle component, which currently only exists in the g2 repository.

The current situation

I had a look at ColorCircle in order to understand what functionality it packs. ColorCircle visually represents a single color, and can also be interactive. The component has a few props:

• The color prop (obviously), which internally seems to be any value that the tinycolor2 library can parse
• The variant prop has 2 values: when default, the component will be in the shape of a circle. When pill, the component will stretch to fill 100% of the available width (while keeping rounded ends)
• The size prop (small, medium, large)
• It can be static or interactive, depending on the value of the isInteractive prop. When interactive, the cursor changes to a pointer, and visually reacts to being clicked/pressed and focused
• When the isActive prop is true, it displays a "tick" icon in the middle
• It also accepts other props (e.g. onClick, which in the prototype is used to open a ColorPicker popover)

After that, I looked at what components with a similar "scope" are currently available in Gutenberg, and I found a few components of interest. In particular:

• ColorIndicator: a very simple component, which as of now just shows a color inside a little rectangular <span />. It doesn't offer any interactivity out of the box either.
• CircularOptionPicker: this seems to be what is currently being used in Gutenberg for color swatches. I'm not particularly a fan of this "family" of components for a few reasons:
  • CircularOptionPicker is quite an opinionated and high-level component
  • It’s not implemented using “g2” features like Emotion, Context, ...
  • Similarly to ColorCirle, its name hints at the circular shape, which makes it much less flexible in terms of design updates. It also doesn't hint at all at the fact that it's mainly used for colors either (and therefore difficult to discover in the library
  • Its set of subcomponents are exposed via namespacing, e.g. <CircularOptionPicker.Option >, which is not in line with other families of components

The next steps

Given all of the above, I'm not certain on what is the best way forward here:

1. Simply adding the g2 ColorCircle component over to Gutenberg would introduce too much overlap with existing components. On top of that, I don't believe that ColorCircle is a good name either, since it will prevent the component from ever taking a different visual shape.
2. Another option (also suggested by @tyxla ) would be to "enrich" ColorIndicator by replacing its implementation with the one from g2's ColorCirlce. We could tweak the variant prop and make the default value look and behave like the current implementation of the component (and introduce a circle variant, in addition to pill). But this would then introduce a significant overlap with the CircularOptionPicker component.
3. We could replace usages of ColorCircle in the prototype with CircularOptionPicker.Option — although I'm not a fan at all of the CircularOptionPicker components “family”, as highlighted above.
4. We could deprecate both ColorIndicator and CircularOptionPicker (as suggested by @griffbrad). We could either leave them as-is or refactor them to use ColorCircle internally (I doubt they're widely used outside of the higher-level palette and color picker components, so it's unlikely to both many 3rd-party devs)

...or any other approach that I haven't listed! What do folks think is the best way forward?

[ciampo]

Notes from the initial round of feedback:

For the primitive component that represents a color, we proposed the name ColorSwatch — we’d prefer to move away from the “circle” and “circular” naming because they tie us to a particular presentation choice without conveying anything meaningful about the behavior of the components. While G2's ColorCircle used an isInteractiveprop to determine whether the component was clickable, we may want to simply include 2 components instead (similar to the divide between ColorIndicator and CircularOptionPicker.Option currently). We’ll experiment a bit to determine which approach feels more natural. The proposed designs for Global Styles more consistently associate a name with each color, which is important for accessibility and themes with meaningful custom color names. This primitive component may need to be responsible for rendering a tooltip with its name, but we may prefer to rely on higher-level components frequently composed with ColorSwatch for tooltips instead.

When it comes to those higher-level components, the Global Styles designs still call for something like ColorPalette/CircularOptionPicker. However, where those components appear and what responsibilities they assume will change. We noted that the custom color and clear/reset features of ColorPalette may be assumed by other components like the newly introduced ToolsPanel. And rather than rendering a palette of color options directly in the sidebar, we’ll be moving toward using ItemGroup to group color attributes (e.g. “Background Color”, “Text Color”, “Border Color”). In Global Styles, clicking an Item will drill-down to another sheet displaying the available color options and related components. In block sidebars, this action will likely result in a popover with similar controls. In the context of these ItemGroup components, we’ll have to consider how the current color selection is communicated to screen reader users and color blind users.

[jasmussen]

We noted that the custom color and clear/reset features of ColorPalette may be assumed by other components like the newly introduced ToolsPanel. And rather than rendering a palette of color options directly in the sidebar, we’ll be moving toward using ItemGroup to group color attributes (e.g. “Background Color”, “Text Color”, “Border Color”). In Global Styles, clicking an Item will drill-down to another sheet displaying the available color options and related components.

To visualize this, there are some good mockups in #34574 that illustrate the behavior above. Instead of duplicating all available color palettes for each a single item in a group is shown as a swatch plus a label:

Click an item in the group drills down to a dedicated subpanel showing all available color tools:

[jasmussen]

Here's an additional mockup that shows how the full flow for collapsible color swatches could work when used in editor inspector panels:

Please note that the precise visuals are subject to change per further work in #34574, so definitely defer to that ticket as the source of truth.

Essentially, multiple color properties are grouped together in an ItemGroup, as swatch+label.

• In global styles, clicking the swatch+label item slides the inspector and shows all palettes and color tools.
• In editor inspectors, clicking the swatch+label item opens a popover that shows all palettes and color tools. This popover has two states, showing the palette and then showing the color tool.

[ciampo]

Closing in favour of #35093