CSS color-mix() Now Accepts Multi-Color Blends in Firefox 150

Firefox 150 stable shipped on April 21, 2026 and the 150.0.3 dot release landed on May 12. The version removed the two-color limit on CSS color-mix() and added light-dark() support on images. Chrome shipped multi-value color-mix() earlier this year. With Firefox 150 now matching, the cross-browser baseline for multi-color blending in a single CSS expression is real. For Phoenix Studio brand audits, that matters because most B2B SaaS Webflow sites I review carry 20 to 40 hand-coded color tokens, half of which are tints and shades of two or three brand primaries. Multi-value color-mix() collapses those tokens into derived expressions in Webflow Variables and ends the dark-mode drift that survives between redesigns. In this piece I walk through the change, the refactor pattern, and what stays hand-coded.

What changed in Firefox 150's color-mix() and light-dark() support?

Firefox 150 removed the two-color limit on CSS color-mix() and added light-dark() support to images. The color-mix() function now accepts an arbitrary number of color values inside a single declaration, and light-dark() works on image properties the same way it works on color properties. The April 21 stable release and the May 12 150.0.3 dot release ship the same feature set for these two changes.

The full release notes are documented in Mozilla's Firefox 150 release notes. The MDN reference for color-mix() and light-dark() reflects the updated specification. The CSS Color Module Level 5 spec at the W3C describes the underlying behavior that Firefox now implements. For Webflow designers, the practical implication is that color tokens previously requiring multiple Sass intermediates or hand-coded variations can now be derived from base values in a single line.

How is multi-value color-mix() different from a CSS gradient?

Multi-value color-mix() produces a single resolved color, not a gradient. A gradient transitions across multiple colors across a spatial axis, like background-image: linear-gradient(red, blue, green). Multi-value color-mix() blends multiple colors into one resolved color value, like color-mix(in srgb, red, blue, green), which produces one color that is the mixed result of the inputs. The two functions solve different design problems.

The practical Webflow application of multi-value color-mix() is for derived brand tokens where the design system needs an intermediate color computed from multiple sources. A typical example is a hover state that is 30 percent of the primary brand color, 20 percent of the accent, and 50 percent of the neutral base. Before Firefox 150 caught up with Chrome, this required either a Sass build step or three nested color-mix() calls that the previous spec did not support cleanly. Now the expression fits in one line and works in every modern browser.

Why does this matter for Webflow Style Variables specifically?

Webflow Style Variables can now hold multi-value color-mix() expressions as their values, which means a derived brand color can live as a single variable referencing other variables. The design system in Webflow becomes cleaner because the relationships between colors are explicit in the variable definition rather than spread across multiple hand-coded steps. Cross-browser baseline support means the variable resolves correctly for every site visitor.

The connection to the layered design token pattern I have written about before is direct. Layered tokens depend on the ability to express derivation rules cleanly. When the derivation requires three or more inputs, the previous color-mix() limit forced workarounds. Firefox 150's update closes that gap. For Phoenix Studio brand audits, this is the difference between a Webflow Variables panel that documents the brand system clearly and one that obscures the brand system behind manual interpolations.

Should I refactor my Webflow brand tokens to use color-mix() today?

Yes, for B2B SaaS Webflow sites with more than 20 hand-coded color tokens that include obvious derivations from a smaller base palette. The refactor pays off in three ways: fewer tokens to maintain, automatic alignment across light and dark modes, and clearer documentation of the brand system inside Webflow Variables. The refactor is a Designer-side activity that takes about 2 to 3 hours per site for a typical mid-sized brand.

The refactor pattern I use at Phoenix Studio starts by listing every color token in the Webflow Variables panel and grouping them by their relationship to a base color. Tokens that are clearly tints, shades, or blends of base colors become color-mix() expressions referencing the base variables. Tokens that have no clear derivation rule stay hand-coded. The result is typically a 30 to 50 percent reduction in token count without losing any visual fidelity in the rendered design.

How does light-dark() on images change Webflow dark-mode design?

The light-dark() function on images lets designers specify two image sources, one for light mode and one for dark mode, in a single CSS expression. Before Firefox 150, light-dark() worked on color properties but not on image properties. The May 12 update closes that gap, so a single declaration can now resolve to the correct image asset based on the user's color-scheme preference, without JavaScript or media queries.

For Webflow B2B SaaS sites with brand assets that differ between light and dark themes, like logo lockups with different fills, this is the cleanest implementation pattern available. The Webflow Designer side is to upload both image assets, reference them with a light-dark() expression in custom CSS or in a Webflow Variable, and let the browser handle the swap automatically. No more JavaScript-based theme detection that breaks on the first paint. The discipline I covered in contrast-color and accessibility pairing applies to the same overall theme-resolution pattern.

What is the cross-browser baseline as of May 16, 2026?

The cross-browser baseline for multi-value color-mix() as of May 16, 2026 is Chrome (shipped earlier in 2026), Firefox 150 stable (April 21), and Safari Tech Preview with stable rollout pending. Edge inherits from Chromium and ships the feature in current versions. For B2B SaaS Webflow sites, this means the feature is safe to use on production sites today, with Safari users on the latest stable seeing the same rendering as Chrome and Firefox users.

The Interop 2026 dashboard tracks cross-browser feature parity in real time and shows multi-value color-mix() at substantially full support across the major engines as of mid-May. The MDN reference and Can I Use both reflect the current state. For Phoenix Studio's typical client mix, where the analytics show Chrome at 60 to 70 percent, Safari at 15 to 20 percent, and Firefox at 5 to 8 percent of traffic, the baseline is firmly safe to ship. The remaining edge cases for very old Safari versions are handled by the natural fallback behavior of the cascade.

Does this affect how Material 3 Expressive themes render on Webflow?

Yes, in a useful way. Material 3 Expressive's color system uses derived tonal palettes generated from a small set of source colors. The token relationships in Material 3 Expressive map cleanly to color-mix() expressions, which means a Material-inspired theme can now be implemented in Webflow Variables with substantially fewer hand-coded tokens. The Expressive system's emphasis on dynamic color benefits directly from the multi-value capability.

The implementation pattern is to define the source colors as base Webflow Variables, then express the secondary, tertiary, and surface containers as color-mix() derivations of the base set. The previous workaround for this on Webflow required either a separate Sass build or external token-generation tools like Style Dictionary. Both approaches added complexity that did not fit a one-person Phoenix Studio workflow. The native Webflow Variables approach with multi-value color-mix() is now the cleanest path.

When should I still fall back to hand-coded color tokens?

Fall back to hand-coded color tokens when the color has no clear derivation rule from a smaller base, when the color is locked by a brand guideline that specifies an exact hex value, or when the color is used in contexts that require precise contrast ratios that derived expressions might shift. The discipline is to derive what can be derived cleanly and hand-code the rest, not to force every token into a derivation just because the capability exists.

A typical Phoenix Studio refactor finishes with roughly 60 to 70 percent of color tokens as derived color-mix() expressions and 30 to 40 percent as hand-coded base values. The hand-coded base set is typically four to six colors that establish the brand identity. Everything else flows from those. The exception is the contrast-critical tokens for accessible text on colored backgrounds, which I still hand-code and audit against WCAG AA standards rather than computing from derivations. The piece on accessibility token pairing covers this exception in detail.

How do I test color-mix() expressions in the Webflow Designer canvas?

Test color-mix() expressions in the Webflow Designer canvas by entering the expression as the custom value for a Webflow Variable, applying the variable to a test element on the canvas, and visually inspecting the resolved color. The Designer canvas renders the expression in real time. For more complex expressions involving multiple variables, the Designer's color picker preview shows the resolved color alongside the expression text.

The verification pattern I use is to render the new derived token alongside the old hand-coded token on the same canvas and visually confirm the result matches. If the result drifts, the expression needs adjustment to match the original brand intent. If the result matches, the refactor is safe to commit. The Designer canvas is a faster verification surface than DevTools because the visual side-by-side comparison is immediate. The piece on the Webflow Premium plan capability list covers the broader Designer feature surface that supports this refactor work.

Where will the CSS Color Module Level 5 spec go next?

The CSS Color Module Level 5 spec at the W3C continues to evolve toward more powerful color manipulation capabilities, including relative color syntax for transforming individual color components and additional color spaces for wider gamut displays. The W3C CSS Working Group has multiple open proposals in this area, and the Interop 2026 cross-browser priorities suggest steady progress through the rest of the year.

For Webflow B2B SaaS sites, the practical implication is that the design token architecture established with multi-value color-mix() today will likely accommodate the next round of Color Module Level 5 features without requiring a rebuild. The investment in cleaner derived tokens pays off across multiple specification updates. The discipline that compounds is to express the brand system in terms of relationships between colors rather than as a flat list of hex values, regardless of which specific CSS features happen to be supported in the current browser baseline.

If you are refactoring a Webflow brand system to use multi-value color-mix() and want to talk through the token reduction pattern for your specific site, drop me a line and tell me how many color tokens currently live in your Webflow Variables panel. I will share the audit pattern I am running on Phoenix Studio client brand systems this month. Let's chat.