The proposed API for the color provider currently has a knowledge of color formats. Problem is these are language specific. In the case of CSS there are even more formats coming.

Therefore I'd suggest the following API instead of the currently proposed resolveDocumentColor

export interface DocumentColorProvider {
// ...
/**
 * Provide the string representations for a color.
 */
   provideColorPresentations(colorRange: ColorRange):ProviderResult<ColorPresentation[]>;
}
interface ColorPresentation {
   label: string;
   type?: string;
   insertText?: string;
   additionalTextEdits?: TextEdit[];
}

Given a color value (e.g. {red:1, green:0, blue:0}) , the provider returns a number of possible presentations: (#FF0000, rgb(255, 0, 0), hsl(0, 100%, 50%), red) that apply at the given range.

The color picker can let the user toggle through the different presentations.
While the color picker is open and the user looks at different colors, new presentation requests will be sent to the provider for each color value. The color picker label will be updated once the result arrives.

• the request also contains the range of the color. That's for the case of embedded languages or languages that have location specific presentations.
• the response has a mandatory label field which is used as label to show to the user in the color picker.
• if insertText is provided, the insertText will be used if the when the color picker decides to apply that color presentation at the given color range. If no insertText is provided, the label will be used as insertText.
  If there is a need for it, insertText could also support SnippetString.
• if additionalTextEdits are set, these edits can be additionally applied (e.g. for adding an import statement)
• the type file is optional. The idea is that the same type of presentation (e.g. hsl) always gets the same type (type: hsl). That way the color picker can stick with the same presentation type while the user browses through different colors.