Add a colorMixPolyfill option to @tailwindcss/postcss - #20444
Conversation
The compiler always emits the color-mix() compatibility pair — a plain fallback declaration plus the original gated behind @supports (color: color-mix(in lab, red, red)) — for browsers without color-mix() support (Safari < 16.2). For projects whose browser floor is at or above Tailwind's own supported targets, the gated arm always wins and the fallback arm is dead bytes on the render-blocking path. Measured in a large app: 342 duplicated @supports blocks, ~42KB decoded / ~4KB gzipped, with zero rendering difference on every supported browser. colorMixPolyfill?: boolean (default true, existing behavior unchanged) masks Polyfills.ColorMix out of the compile, mirroring how the plugin already varies the polyfill set per input (Polyfills.All ^ Polyfills.AtProperty for CSS Modules). The compiler-cache key gains the flag so two configs sharing an input file cannot reuse each other's compiler.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains, and the previously missing public documentation has been added. Reviews (2): Last reviewed commit: "Document colorMixPolyfill in the package..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| /** | ||
| * Emit `color-mix(…)` fallbacks for browsers without `color-mix()` support | ||
| * (Safari < 16.2): a plain fallback declaration, plus a copy of the original | ||
| * declaration gated behind `@supports (color: color-mix(in lab, red, red))`. | ||
| * | ||
| * Defaults to `true`. Set this to `false` when every browser you support has | ||
| * `color-mix()`, which removes the duplicated declarations from the output. | ||
| */ | ||
| colorMixPolyfill?: boolean |
There was a problem hiding this comment.
The package README documents the existing public plugin options, but not colorMixPolyfill. Add this option alongside them so configuration-file users can discover its default and understand the browser-compatibility tradeoff.
Knowledge Base Used: PostCSS plugin
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Added in 2cd26db: a "Enabling or disabling the color-mix(…) polyfill" section in the package README, alongside the existing option docs, with the default and the browser-compatibility tradeoff.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. WalkthroughThe PostCSS plugin adds an optional Merge Risk: ⚪ Minimal · up to The new option only disables color-mix fallback CSS when explicitly requested; existing users retain current output, while opted-in projects may ship smaller stylesheets for browsers in their supported range. No actionable merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 188c1462-b12a-488c-84fa-cd813f345869
📒 Files selected for processing (3)
CHANGELOG.mdpackages/@tailwindcss-postcss/src/index.test.tspackages/@tailwindcss-postcss/src/index.ts
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.
…wrapper in the default-arm test
1 participant
The compiler always emits the
color-mix()compatibility pair — a plain fallback declaration plus the original gated behind@supports (color: color-mix(in lab, red, red))— for browsers withoutcolor-mix()support (Safari < 16.2). For projects whose browser floor is at or above Tailwind's own supported targets, the gated arm always wins, so the fallback arm is dead bytes on the render-blocking path.Measured in a large production app: 342 duplicated
@supportsblocks, ~42KB decoded / ~4KB gzipped of the main stylesheet, with zero rendering difference on every supported browser.The core
tailwindcsspackage already exposesCompileOptions.polyfills(None/AtProperty/ColorMix/All), but no plugin lets a consumer reach it —@tailwindcss/postcsshardcodesPolyfills.All(modulo the CSS-Modules@propertycarve-out). This PR adds the smallest control that covers the case:colorMixPolyfill?: booleanon the PostCSS plugin's options — defaulttrue, existing behavior byte-for-byte unchanged.falsemasksPolyfills.ColorMixout of the compile, mirroring the existing per-input variation (Polyfills.All ^ Polyfills.AtPropertyfor CSS Module files).color-mix() fallbacks can be disabled— the default arm asserts the@supports (color: color-mix(in lab, red, red))marker is present for@apply text-red-500/50; the disabled arm asserts the declaration ships once with no@supportsgate.One honest note on verification: the exact semantics (option name, masking, byte savings) have been running in production via a pnpm patch against
@tailwindcss/postcss@4.3.3; the test in this PR was authored againstmain's suite conventions, and I'd lean on CI here to validate it againstmain's snapshot behavior.A natural follow-up (not in this PR) is the same option on
@tailwindcss/viteand@tailwindcss/cli, which also pass nopolyfillstoday.