in srgb
in oklch
The same two colours, mixed two ways
CaveatThe colour space is required, and it decides the answer: srgb runs the midpoint through grey, which is why a derived hover tint so often looks washed out compared to the swatch the designer picked. Then the percentages, which are the part nobody reads: they are normalised rather than rejected, so 30% and 30% is a 50/50 mix — but because they add up to less than 100%, the result also comes back at 60% alpha. A colour that is both the wrong ratio and quietly translucent, from a line that looks arithmetically fine. currentColor is allowed inside, which is what lets one rule tint every state of a component that has not picked its colour yet.
FallbackAn engine that does not know the function drops the whole declaration, not just the value, so the property falls back to whatever was declared before it in the same block. That fixes the order: the plain colour first, the mix second. Written the other way round the fallback wins everywhere and the mix never applies at all.
.btn:hover {
/* plain first: an engine that drops
the mix keeps this one */
background: #7fb4e2;
background: color-mix(
in oklch, #6fa8dc 75%, #f6b26b);
}
/* 30% and 30% is a 50/50 mix at
60% alpha, not the colour typed */