v147 · CSS · Color

Compatibility Lab

Probe contrast-color() as a real <color> value: valid syntax, rejected syntax, native computed output, and a JavaScript fallback that only takes over when the browser cannot parse the function.

Checking contrast-color(red) support...

CSS.supports() probes

The current grammar is contrast-color(<color>). Valid color arguments should parse; malformed arguments and non-color properties should be rejected.

Live swatch test

checking
Waiting for the first swatch render.

Failure-mode lab

Pick a declaration and watch what the parser accepts. Invalid syntax is dropped, so the sample falls back to the ordinary cascaded text color instead of trying to render a broken function.

This sentence keeps a readable fallback when the declaration is rejected.
CSS.supports()-
Inline declaration-
Computed color-
Why-

Fallback pattern

const supportsContrastColor =
  CSS.supports("color", "contrast-color(red)");

.dynamic-surface {
  background: var(--surface-color);
  color: var(--text-black);
}

@supports (color: contrast-color(red)) {
  .dynamic-surface {
    color: contrast-color(var(--surface-color));
  }
}

// Only for browsers without contrast-color().
// This WCAG-luminance fallback is an approximation; the CSS spec
// intentionally lets browsers choose a better light/dark algorithm.
function fallbackTextColor(color) {
  const rgb = parseColorWithTheBrowser(color);
  const blackRatio = contrastRatio(rgb, [0, 0, 0]);
  const whiteRatio = contrastRatio(rgb, [255, 255, 255]);
  return whiteRatio >= blackRatio ? "var(--bg-paper)" : "var(--text-black)";
}

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗