Add OKLCH color support to Storybook

[nikwilliamson]

Is your feature request related to a problem? Please describe.

We recently migrated our design system's color tokens from hex to OKLCH for better perceptual uniformity across our palette. After the migration, two things broke in Storybook:

1. ColorItem / ColorPalette blocks in our MDX documentation pages throw the error: "Couldn't parse the color string. Please provide the color as a string in hex, rgb, rgba, hsl or hsla notation." These blocks are a core part of how we document our color system, and they don't accept OKLCH values at all.

2. Storybook's theming system crashes with PolishedError because @storybook/theming's create() function runs color values through polished's parseToRgb / opacify internally, which has no OKLCH support. Any theme that passes a design token value as a color — which is the intended usage — breaks immediately.

OKLCH is a CSS Color Level 4 spec that's been supported in all major browsers since 2023. Design systems are adopting it because it provides perceptually uniform lightness and predictable chroma scaling — things that hex/HSL can't offer. Storybook's color handling hasn't kept up with this.

Describe the solution you'd like

• ColorItem and ColorPalette should accept any valid CSS color value, including oklch(), oklab(), lch(), lab(), and color().
• @storybook/theming's create() function should handle modern CSS color formats without crashing. If polished can't parse them, Storybook should either replace polished with a modern color library or add a fallback path that sets colors via CSS properties directly.
• Color controls in the addon panel should be able to display and edit OKLCH values.

Describe alternatives you've considered

• Removed all ColorItem blocks from our documentation and replaced them with a custom TokenVisualizer component that renders swatches via CSS backgroundColor (which browsers handle natively). This works, but we lose the built-in Storybook doc patterns.
• Added a build step in our Style Dictionary pipeline that converts OKLCH back to hex specifically for JS token exports consumed by the Storybook theme. This is a workaround — we shouldn't need to maintain a parallel color format just for Storybook's internals.
• Both of these are functional but add maintenance overhead and defeat the purpose of having first-party color documentation blocks.

Are you able to assist to bring the feature to reality?

no

Additional context

The root of the issue is polished — it's used internally by @storybook/theming and doesn't support any CSS Color Level 4 formats. The parseToRgb function only handles hex, rgb(a), and hsl(a). Since polished hasn't been actively maintained, it might be worth considering a switch to a library like culori or even native CSS parsing via <canvas> context for color conversion.

OKLCH adoption is accelerating across design systems (see Evil Martians' guide, Adam Argyle's work on Open Props, and the Tailwind CSS v4 migration to OKLCH). This is quickly becoming the standard for design token authoring, and Storybook's color tooling should support it.

Relevant Storybook internals affected:

• @storybook/addon-docs — ColorItem, ColorPalette blocks
• @storybook/theming — create(), color processing via polished
• @storybook/addon-controls — color picker/control type