Do not wrap color-mix in a @supports rule if one already exists

[hirasso]

Related issue: #19445

Summary

Fixes an issue where tailwindcss wraps color-mix inside a @supports block even if the original code already checks for support.

Uncompiled Code:

@utility foo {
  @supports (color: color-mix(in lab, red, red)) {
    background: color-mix(in lab, var(--color-1), var(--color-2));
  }
}

Compiled code: Current behavior

https://play.tailwindcss.com/KSvR7wefdh?file=css

@layer utilities {
  .foo {
    @supports (color: color-mix(in lab, red, red)) {
      background: var(--color-1);
      @supports (color: color-mix(in lab, red, red)) {
        background: color-mix(in lab, var(--color-1), var(--color-2));
      }
    }
}

Compiled code: Fixed behavior

@layer utilities {
  @supports (color: color-mix(in lab, red, red)) {
    .foo {
      background: color-mix(in lab, var(--color-1), var(--color-2));
    }
}

Test plan

I have tested this by writing a new test that was at first failing. Now it passes.

[coderabbitai]

Walkthrough

The PR updates the Tailwind CSS AST transform to detect @supports at-rules whose params contain color-mix(. When such a @supports block is encountered, its child nodes are processed with a supportsColorMix flag set to true and handling of the original node stops. The transform now also avoids collecting color-mix polyfill declarations when supportsColorMix is true and propagates this flag through nested transforms. Tests were added asserting that color-mix optimizations are not applied inside @supports(color: color-mix(...)) blocks.

Pre-merge checks

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description provides clear context with before/after code examples, references the related issue, and explains the test validation approach.
Title check	✅ Passed	The title directly and accurately describes the main change: preventing double-wrapping of color-mix in @supports rules when one already exists.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 73b5df6 and 04df8c3.

📒 Files selected for processing (3)

• packages/tailwindcss/src/ast.ts (2 hunks)
• packages/tailwindcss/src/index.test.ts (1 hunks)
• packages/tailwindcss/src/utilities.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

packages/tailwindcss/src/index.test.ts (2)

packages/tailwindcss/src/test-utils/run.ts (1)

• compileCss (4-11)

integrations/utils.ts (1)

• css (519-519)

🔇 Additional comments (4)

packages/tailwindcss/src/ast.ts (2)

296-304: Logic is correct, but depends on the fix for lines 243-253.

The condition !context.supportsColorMix correctly prevents collecting color-mix declarations for polyfill generation when already inside a @supports (color: color-mix(...)) block. This avoids the double-wrapping issue described in the PR.

However, this change depends on the supportsColorMix flag being correctly set and propagated. As noted in the previous comment, the implementation at lines 243-253 appears to have an issue that may prevent the @supports node from being included in the output.

---

243-253: No action needed—the implementation is correct.

The @supports block is intentionally not preserved from the input. When the transform encounters @supports (color: color-mix(...)), it processes children with the supportsColorMix: true context flag (preventing them from needing individual polyfills since they're already protected by the browser check), then discards the original node. Later, new @supports blocks are generated (line 622) as part of the polyfill mechanism for declarations that actually need them. Tests confirm the output includes @supports blocks as expected, generated fresh during the polyfill creation phase.

packages/tailwindcss/src/index.test.ts (1)

5816-5836: Test title mismatch: actual title is "should not apply color-mix optimizations when already inside a @supports at-rule that checks for color-mix"

The test code is correct and properly verifies that no additional fallback is generated when color-mix is already nested in an @supports block. The existing test suite provides comprehensive coverage of color-mix polyfill behavior across 14 test cases. While additional edge case tests for deeply nested @supports or multiple color-mix calls within the same block could be valuable, the current test validates the intended behavior correctly.

Likely an incorrect or invalid review comment.

packages/tailwindcss/src/utilities.ts (1)

197-205: LGTM! Clean utility functions for optimize comment handling.

The regex pattern and helper functions are well-implemented:

• Pattern correctly matches the /* tw:optimize */ comment at the start with proper escaping
• containsOptimizeComment() provides a clean boolean check
• removeOptimizeComment() safely strips the marker

These utilities support the color-mix optimization feature described in the PR.

Note: These functions will only work correctly once the comment prefix is actually added in the withAlpha() function (see previous comment).

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7159256 and d1410dc.

📒 Files selected for processing (1)

• packages/tailwindcss/src/index.test.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

packages/tailwindcss/src/index.test.ts (1)

packages/tailwindcss/src/test-utils/run.ts (1)

• compileCss (4-11)