The first uses oklch(0.65 0.20 300), comfortably inside sRGB, not even at the boundary. The second uses oklch(0.65 0.28 300), which is well outside P3 and even Rec.2020.
The smallest fix would be to make the second one oklch(0.65 0.2399 300) to bring it inside P3 so the demo doesn’t get slightly warped if Rec.2020-capable (not really necessary, but preferable, I’d say), and the first #a95eff (oklch(0.6447 0.2297 301.67)) which is CSS’s fallback.
But purple is also pretty much the worst choice for such a demo—P3 adds the least to sRGB around there, so the difference will be smallest. A better choice is red or green.
So a better pair would be oklch(0.65 0.2977284 28) on the right (a bright red at the very edge of the P3 gamut, well outside sRGB) and #f00 on the left (the sRGB value CSS will map it to if out of gamut).
Moving the monochromatic BT.2020 colors from 630 nm, 532 nm and 467 nm could get a little increase in color space coverage, but at the expense of a lower efficiency in power consumption to brightness conversion. 467 nm is not a very pure blue, but the sensitivity of the eye drops very quickly in the blue region, so a better blue would require much more power. Similarly, though not so pronounced, for a different green.
Moreover, in the green region there is a gap, both for lasers and for LEDs, where the available devices have low efficiencies for converting electrical power to light, so changing the frequency of the primary green color would have to take that into account too.
In conclusion, I believe that the BT.2020 (actually BT.2100) color space is close to the best that can be done in displays of reasonable price and energy efficiency.
A true coverage of 100% of the BT.2100 color space can be realized only with laser projectors. Any display with LEDs or quantum dots will never have really monochromatic primary colors, though a coverage of significantly more than 90% of the BT.2100 color space is not too difficult. However, the advertised percentage of the color space may be misleading, because it varies depending on the kind of color space used for computations. A coverage percentage computed in OKlab would be more informative than a percentage computed in the XYZ color space.
I was referring to the new RGB LED. From what I have read so far seems to be doing far better than LED or quantum dots.
But I guess we will have to settle with BT2100 then.
Unless you want to make displays for the bees and birds (and the tiny alleged minority of human tetrachromats) that seems rather pointless. People with three color receptors are your customers, so that's driving the market.
I rather predict, future displays will further improve on contrast, including very bright (brilliant) sparks. Imagine an iPhone glittering like gold or diamonds ...
The border of the color space corresponding to monochromatic colors is convex, so any triangle inscribed in that curve border will leave parts of the color space that cannot be reproduced on a display.
The convexity of the border means that if you compute the 3 coefficients of RGB colors that match a desired color, there will always be some colors that need one negative coefficient, regardless of the choice for the RGB primary colors. On any display, it is impossible to realize a negative brightness of a color, so on a RGB display there will always be some colors whose hue and brightness can be reproduced, but their saturation cannot be reproduced.
The only way to make smaller the parts of the color space that cannot be reproduced is to take more points on the monochromatic border, replacing the triangle of reproducible colors with a polygon that fits more closely the curved border.
The entire color space perceived by humans could be reproduced on a display only with tunable lasers, not with fixed-frequency primary colors. One could use fixed-frequency primary colors only if they would stimulate directly the photoreceptors in the eye, to enable workarounds for the overlapping filter characteristics of the cones and for the signal processing done in the retina.
One last thing:
> This way the browser uses OKLCH colors if they are supported, otherwise it falls back to sRGB.
This wording suggests it’s about gamuts, but it’s actually about syntax. It will use the oklch() if that syntax is supported, and then the OKLCH value may be within sRGB or may be in another gamut the screen is using or may need to be mapped back to the screen’s gamut. Whereas #rgb values are inherently limited to sRGB, the baseline.