[Bug] bg-black/50 silently fails — NaN oklab channels from lightningcss color-mix resolution

[alimaan2935]

Before submitting a new issue

• I tested using the latest version of the library, as the bug might be already fixed.
• I tested using a supported version of react native.
• I checked for possible duplicate issues, with possible answers.

Bug summary

bg-black/50 (and any opacity modifier on black) silently produces no style on React Native. The background/border is either invisible or loses its opacity. All other colors work
correctly (bg-red-500/50, bg-white/50, border-white/50, etc.).

Library version

3.0.6

Environment info

System:
    OS: macOS 26.3.1
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.14.0
    npm: 11.9.0
  SDKs:
    iOS SDK: iOS 26.2
  IDEs:
    Xcode: 26.3/17C529
  npmPackages:
    expo: ~55.0.9
    react: 19.2.0
    react-native: 0.83.4
    react-native-css: 3.0.6
    nativewind: 5.0.0-preview.3
    tailwindcss: 4.2.2
    lightningcss: 1.30.1
  Expo Workflow: managed

Steps to reproduce

https://github.com/alimaan2935/nativewind-color-mix-bug-repro

git clone https://github.com/alimaan2935/nativewind-color-mix-bug-repro
cd nativewind-color-mix-bug-repro
npm install
npx expo start --clear

Reproducible example repository

https://github.com/alimaan2935/nativewind-color-mix-bug-repro

[alimaan2935]

Claude code suggested the root cause below:

lightningcss resolves color-mix(in oklab, #000 50%, transparent) and produces NaN for the oklab a and b channels. Black in oklab is [l=0, a=0, b=0], but transparent
has undefined color channels in CSS. When mixed at zero lightness, the chromaticity channels
become NaN (degenerate case).
parseColorindeclarations.jspasses theseNaNcoords tocolorjs.io, which produces #NaNNaNNaN80 — an invalid color string that React Native silently discards. White works because its oklab values are all numeric (l:1, a:0, b:~5.96e-8`) — lightness
is non-zero, so the chromaticity channels don't degenerate.

and proposed this fix which actually works for my use case:

In parseColor (declarations.js), guard against NaN with || 0 for lab/lch/oklab/oklch.
Note: NaN ?? 0 does NOT work — NaN is not nullish. NaN || 0 is needed.

     case "oklab":
       color = new Color({
         space: cssColor.type,
-        coords: [cssColor.l, cssColor.a, cssColor.b],
+        coords: [cssColor.l || 0, cssColor.a || 0, cssColor.b || 0],
         alpha: cssColor.alpha
       });
       break;

Same for oklch, lab, and lch cases.

[danstepanov]

Tried reproducing with a direct registerCSS('.bg-black\/50 { background-color: rgb(0 0 0 / 0.5); }') on HEAD and it compiles correctly to #00000080. However, the issue is likely in how Tailwind v4 generates the CSS for bg-black/50 (using color-mix() or oklab() rather than plain rgb()), which then hits a lightningcss edge case during compilation.

Need to repro with an actual Tailwind v4 compilation pipeline to confirm. Leaving open.

[github-actions]

🤖 Auto-triage

Status: CONFIRMED
Type: bug
Version: v5

Findings

Confirmed the bug. color-mix(in oklab, #000 50%, transparent) (and the black keyword variant) compiles to the literal string #NaNNaNNaN80 at runtime, which React Native silently discards. The reporter's diagnosis is accurate: lightningcss resolves color-mix at compile time, and mixing pure black with transparent in oklab produces NaN for the a/b chromaticity channels (degenerate case at zero lightness), which parseColor in src/compiler/declarations.ts:1667 passes verbatim into colorjs.io.

Note: when the source color is referenced through a CSS variable (--bg: black; ... color-mix(in oklab, var(--bg) 50%, transparent)), lightningcss does NOT pre-resolve the mix and the runtime path produces correct output. The bug only triggers when lightningcss can statically evaluate the color-mix(), which is exactly what Tailwind v4 produces for bg-black/50.

What I tested

• Wrote a Jest test at src/__tests__/native/triage-317.test.tsx with three cases:
  • color-mix(in oklab, #000 50%, transparent) → FAIL, output #NaNNaNNaN80
  • color-mix(in oklab, black 50%, transparent) → FAIL, output #NaNNaNNaN80
  • color-mix(in oklab, var(--bg) 50%, transparent) with --bg: black (inlineVariables: false) → PASS
• Reviewed parseColor in src/compiler/declarations.ts (lines 1653–1680) — lab/lch/oklab/oklch cases pass cssColor.{l,a,b} / {l,c,h} directly into new Color({...}) with no NaN guard.
• Confirmed against current HEAD (published v3.0.7).

Next steps

• The proposed fix (cssColor.l || 0 etc. in the four lab/lch/oklab/oklch cases of parseColor) is correct and minimal. || 0 is required since NaN ?? 0 does not coerce.
• A regression test should be added under src/__tests__/native/color-mix.test.tsx covering both #000 hex and the black keyword resolved through color-mix(in oklab, ..., transparent).
• Worth also verifying the same degenerate case for pure white through oklch (hue is undefined for achromatic colors) and for lab/lch color spaces.

---

_{This is an automated triage. See auto-triage.yml.}

[danstepanov]

Correction on my earlier comment — the auto-triage above is accurate. You don't need a full Tailwind pipeline to reproduce; a minimal registerCSS('.x { background-color: color-mix(in oklab, #000 50%, transparent); }') produces #NaNNaNNaN80 on HEAD. The fix path (|| 0 guards in the lab/lch/oklab/oklch cases of parseColor in src/compiler/declarations.ts) is correct.