Post

There's actual gamut mapping of wide-gamut colors in Firefox Nightly- I'm going to play around with it a bit and see how it's working. It's in Firefox Nightly 153, by setting layout.css.gamut-mapping.method to 2.

From the first glance, things are looking good- way better than clipping! I'm using the apps.colorjs.io/gamut-mappin... tool to do some comparison. None is the browser's GMA, compared to the Raytrace and CSS (Binary Search) algorithms, and then naive clipping (which is what is active in browsers).

CSS Color 4 specifies 3 algorithms that can be used, and Firefox implemented Binary Search (in the gradients tool as "CSS") and Ray Trace. I'm testing out Ray Trace, which is a bit faster yet not as precise.

For comparison, here is the current state of Firefox - note how it matches the Clip gradient, where values outside of the gamut (I forget which one, is it rec2020? P3? The display?) are just clipped, which skews the colors to be much more saturated.

Now things are getting interesting. It looks like the color `oklch(90% .1 20)` is getting rendered by Firefox much more lavender than expected, and doesn't match the ColorJS implementation. Note the final step here is inside rec2020, while everything else is outside, which may be why.

The jump to lavender seems to be happening right on the edge of the gradient- I "zoomed in" on the gradient, with linear-gradient(to right, oklch(90% 0.11 375.67), oklch(90% .1 20)), and there's a sudden jump to lavender right at the end.

By default, gradients are interpolated in Oklab. Switching to OkLCh shows another oddity, with a random jump to a bluish green.

I'm guessing there's a bug somewhere in Firefox's render- very specific colors are rendering wildly incorrect, like in this extremely narrow gradient.

Before I call it a night, I wanted to check in on @nerdy.dev's lovely gradient.style. If you have been relying on browser's clipping to create gradients as vibrant as possible, gamut mapping will be a bit disappointing.

I think this is a good call, especially for relative color syntax and accessibility, but it's a shame it comes at the cost of what has been a flashier use case with bright gradients.

"Interesante, entonces la prioridad de CSS es la accesibilidad y el contraste, aunque a costa de la vibración de los colores. ¿Cómo se puede equilibrar esto en diseños que requieren colores brillantes? #CSS #Accesibilidad"

Good question- you can still use vibrant colors, and still specify the same colors that are shown on your screen when a color is clipped. But if you specify a color your screen can't display, it will be brought back into gamut to a color that matches the lightness and hue.

So for designs that require brilliant colors- specify those colors. Designers aren't likely to choose colors that their monitor can't display, so solid colors won't run into this.