Auto-Contrast Color Swatch

A row of brand-color swatches whose label text always stays readable, computed by the browser itself from the swatch's own background — no manual per-color text-color lookup table — using the new CSS contrast-color() function: color: contrast-color(var(--bg)) returns whichever of pure black or white has the greater WCAG contrast against --bg, and re-computes automatically if --bg ever changes (a live brand-color picker, a CMS-driven theme value, a user-customized accent color) with no JS re-render needed. This replaces the classic 'ship a hardcoded {color: '#fff'} class or hand-maintained hex-to-textcolor lookup map alongside every background color' pattern most theming systems still carry — exactly the kind of thing that silently breaks (white text on a newly-picked pale yellow) the moment a user or CMS editor picks a brand color nobody manually re-tested for contrast. Real, current (2026), sourced via WebSearch, cross-checked across multiple independent queries (MDN's 'contrast-color() CSS function' reference, CODERCOPS' 'CSS contrast-color() Is Baseline: Stop Hardcoding' and 'Baseline 2026: Three Features Safe to Ship Now', and independent write-ups — Schalk Neethling's 'Accessible Text Colour with the CSS contrast-color() Function', Dan Holloran's 'CSS contrast-color(): Let the Browser Pick Your Text Color' — all describing the same single-argument contrast-color(<color>) mechanism and the same Baseline date). **Cross-checked support, genuinely Baseline this time, not rounded up:** every source found agrees contrast-color() reached Baseline 'Newly available' on 2026-04-10, shipping in stable Chrome 147, Firefox 146, Safari 26.0, and Edge 147 — all four major engines, unlike nearly every other entry in this catalog which has had to flag a Chromium-only or single-engine gap. web-features' own tracking projects Baseline 'Widely available' for 2028-10-10 (the usual multi-year lag for version-distribution catch-up), so this is Newly- not Widely-available — stated precisely rather than either overclaiming universal safety or underselling real four-engine support. **Honest fallback distinction, same category of honesty as this catalog's if()/style() entry:** contrast-color() has no style()-query equivalent to branch on per-swatch inside one declaration, so a naive two-line cascade fallback (one generic color, then the override) would leave non-supporting browsers with a single compromise color that reads poorly on at least some of these six backgrounds. This demo instead uses real, manually color-picked per-swatch fallback text colors as the default rule, wrapped in a positive @supports (color: contrast-color(red)) block that overrides them with the live computed value at matching selector specificity — non-supporting browsers see correct, designer-matched colors (the old way), supporting browsers see the browser's own live computation replace them (the new way) and the explanatory note hides itself. No WebGL, no scroll-jacking, zero JS either way — a pure declarative color swap the cascade and @supports both handle natively. (Vanilla example: live iframe preview + HTML/CSS tabs — six swatches, each with a different --bg custom property.)

<div class="ccb-wrap">
  <div class="ccb-swatch" style="--bg:#0b1224"><span class="ccb-label">Midnight</span></div>
  <div class="ccb-swatch" style="--bg:#fbbf24"><span class="ccb-label">Amber</span></div>
  <div class="ccb-swatch" style="--bg:#38e8b0"><span class="ccb-label">Mint</span></div>
  <div class="ccb-swatch" style="--bg:#7c3aed"><span class="ccb-label">Violet</span></div>
  <div class="ccb-swatch" style="--bg:#f87171"><span class="ccb-label">Coral</span></div>
  <div class="ccb-swatch" style="--bg:#e5e7eb"><span class="ccb-label">Fog</span></div>
  <span class="ccb-note">Manually color-matched fallback shown above. Needs Chrome/Edge/Firefox 147+ (Firefox 146) or Safari 26+ to see the browser compute each label's color live from --bg via contrast-color() instead.</span>
</div>