@brandonkelly Yeah that would work, especially with TW 4 changing to CSS vars now

Jumping in here - the fact I can't get at the colour label honestly feels broken. I was hoping to replace a "Theme colour" Dropdown in our builds with a Color field because it'd be SO much better to see a colour swatch alongside the theme name and not just "Dark Oak" in a dropdown... but the way the Color field is implemented makes that a no-go.

When I have "darkOak" chosen, that doesn't just mean "I want to apply exactly #ff33cc onto one element" or whatever, it means a variety of colours based on that one.

e.g., <div data-colour-theme="{{ fieldHandle.label }}>...</div> because that might be "brandRed" or "attentionRed" or whatever, and I'm not directly applying the field's colour onto single elements - but I do want the client to see the base colour of that theme name in the CMS, because a theme name alone isn't good enough really. "Brand Red 1", "Brand Red 2" is less usefull than also seeing the colour itself as well.

I have never used Colour fields because they don't do what I need from colour fields. Long and short - I was hoping and sort-of-expecting the new Color field to be closer to this plugin. https://plugins.craftcms.com/colour-swatches And kudos, it IS from the back end. But without the front-end component, it's not useful to me.

@brandonkelly +1 for having a handle for each color option in addition to the label and hex code. We have some Dropdown fields to select colors from a pre-defined list, but we're outputting those as CSS classes (section--green, section--red etc) and defining the specific colors in CSS. I would love to switch those to Color fields for the improved AX (being able to see the color), but this would require handles for each color option.

Also +1 for the suggestion by @MattWilcox to get access to the label. I think replacing the hex code with a data object that provides access to the hex value, label and (if added) handle makes sense.

The distinction between label and handle is important in my opinion. I may want darkOak as a value in my templates to use in CSS, but present a human-readable label Dark Oak to authors. Can be done using case conversion, but that's not ideal in all cases.

Honestly, exactly what the Dropdown field type already does - but with a colour being shown in the CMS UI is all I really want.