[RFC] Remove arbitrary preset limit in Color Control

[robbchar]

Summary

The requested feature is here, it was made a bit ago so I wanted to start a discussion about a potential implementation.

Problem Statement

The discussion was about removing the limit for preset colors for swatches under the color picker:

the limit there being 27 with the first 25 being presets and the last two being custom ones. The idea being that the limit would be removed and then a DS with more than 27 colors could show all of them. But, I was thinking, if the user also wants to be able to choose colors, it is currently implicit that that can happen, every time the user chooses a new color that gets added to the list of swatches so if the limit is removed then the list will get infinitely long OR if the limit stays the presets start falling off, neither of which seems good or in the vein of what was being discussed. Also, it's not easy to tell what the accepted preset swatches are vs which are the custom colors.

Non-goals

No response

Implementation

I propose, when there are presets passed in, that there are two lists of swatches:

Sure, it takes up more space but it's easy to see which is which. The presets would never change and the custom ones can be limited, I suggest just 9 but that could be configurable. In fact, based on the last comment in the issue #20298 (comment), you could have multiple lists of presets. If you do not specify presets that list does not show but a config could be added to not allow custom colors which would hide the color picker...

Prior Art

not certain but this doesn't seem terribly original...

Deliverables

No response

Risks

• If many lists of presets are given that could be visually confusing.

Unresolved Questions

• Can the original ask be expanded to using two lists of swatches?
• Multiple preset lists?
• What should be configurable?
  • can add custom?
  • number of possible custom colors?

Alternatives considered / Abandoned Ideas

No response

[Sidnioulz]

I can see how making more use of presets would fit within the world of design tokens. This would be particularly useful if we coud surface color-related CSS variables and match their value to preset design tokens. Yet, there are many elements still missing before we can properly support design tokens in colour pickers (how to extract tokens? how to map them to values consumed inside code? etc.).

An alternative avenue for teams to support design tokens based on their own org/team conventions around token naming and consumption would be to allow custom controls (@shilman don't hate me please 😬).

In the meantime, I agree that we should lift the 25 presets limit. The limit is arbitrary and it costs us very little to remove it. We could try an extreme case with 2000 colours and see how badly we need windowing and scrolling, though anything in the low hundreds should be fine.

I think we could also allow passing categories / groups of presets, or apply our own name parsing to group defined presets (@MichaelArestad WDYT?). We could also consider a boolean flag to remove the picker and force users to pick from a preset. This might be helpful to design system teams. Those features are fairly easy to implement with reasonable documentation footprint.

@robbchar I think in this use case, posting on the issue would have been okay to do. There was general consensus that a change is needed on the issue and you could have spared yourself the RFC process :)

[MichaelArestad]

1. Lifting the limit works for me. No objections here.
2. I would like to consider an update to the color picker (and these types of interactive modals) that are accessible and flexible. Being able to pass in presets or preset groups makes sense to me. I also want to expand the functionality of the ways to input colors. All of this probably needs a proper RFC, but I am noting it for now as I work through modal and menu design updates.