NSColorPanel is the only OS-native color picker that I have seen that supports color space natively, and that's great. The only issue is that I can't seem to find any real way to control the color space used by the color picker, at all.
The issue here is that I'm trying to present a color picker that starts off with an sRGB color, with all controls in sRGB mode. This way, an unsavvy developer (which is the majority of them) who don't understand color spaces won't get surprised when they picked a color and the resulting CSS hex code (CSS is essentially sRGB-only if you developer across different web browsers, sigh) looks different from their in-color-picker color.
The only control I can see, is to pre-set the color with something like panel.color = [NSColor colorWithSRGBRed:1.0 green:0.5 blue:0.2 alpha:1.0];. This will pre-populate the color panel with an sRGB color. In the color panel "RGB" mode, it will actually be correct.
However, if I go to the "wheel" mode, the wheel is still in Display P3 mode. If I select any color here the color will be automatically in P3, instead of in sRGB (you can bring up this menu by right-clicking on the wheel to see and change what the current color space for the wheel is):
This seems like pretty poor behavior, as it makes it impossible to control the user experience, and it's not always desirable to get other color spaces when you get a color back. I can always manually convert the color when I retrieve it for my use, but it could lead to unintuitive behavior, especially if the user goes back and forth between the wheel and RGB modes. (It's unintuitive because the hex value they see will be different from the converted sRGB hex values)
When playing around with Safari's handling of HTML input types (example: https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_color_get), you can actually see this behavior happening. If you go to the wheel, it will start selecting colors in Display P3, and then converts the color to sRGB when providing the color toe the "color" input in the web page. It's theoretically correct, but the user will see different hex values in the color picker from what the final HTML input sees. Interestingly Firefox handles it poorly by just using the selected color component values instead of doing a color conversion, meaning that both #aabbcc in P3 and in sRGB will end up producing #aabbcc in the final input value for the color component, which is wrong for P3 (because CSS assumes sRGB). Chrome is not affected as it does not use the builtin OS color picker, presumably to avoid oddities like this and to have a simplified UI.
Anyone has any input? It really seems like the NSColorPanel needs to provide a little more control about how the color spaces should be handled. It's good that it's color space aware, but not good that we seemingly have no way to control the behavior.