ContrastChecker component doesn't process CSS variables

[goldenapples]

Describe the bug
It's possible to register an editor color palette using CSS variables as colors, like this:

add_theme_support(
    'editor-color-palette', [
        [
            'name' => 'Black',
            'slug' => 'black',
            'color' => 'var( --black )',
        ],
        [
            'name' => 'Red',
            'slug' => 'red',
            'color' => 'var( --red )',
        ],
        [
            'name' => 'White',
            'slug' => 'white',
            'color' => 'var( --white )',
        ],
    ]
);

However, no matter what the CSS variable is defined as, the contrast checker message displays "This color combination may be hard for people to read. Try using a darker background color and/or a brighter text color.".

Expected behavior
I believe this is happening because tinycolor2 evaluates any unrecognized color format as black. It would be better, in cases like this where tinycolor doesn't recognize the color format, to fall back to the detected color from getComputedStyle(), which can properly return the value of the CSS variable.

Desktop (please complete the following information):

• OS: OSX
• Browser Chrome
• Version 80.0.3987.116

Additional context
I tested using the block editor from core 5.3.2, and also using the latest plugin release 7.6.0.

[talldan]

@goldenapples I think it's likely that the color palette wasn't designed to work with css variables (judging by the docs - https://developer.wordpress.org/block-editor/developers/themes/theme-support/#block-color-palettes), so I'm not sure this could be considered a bug, I'll label as an enhancement.