Automatic coordinate resolution from other color spaces?

[LeaVerou]

Currently, if we try to do something like color.get("c") on e.g. an sRGB color, it will fail with:

ColorSpace.js:443 Uncaught TypeError: No "c" coordinate found in sRGB. Its coordinates are: r, g, b

IIRC we recently implemented automatic resolution of formats so that e.g. color.toString({format: 'hex'}) will work no matter what color space color is in. If the specified format is not found on the current color space, Color.js will search other spaces.

What if we did this with coordinates too?
Ideally we'd want some way to specify the priority order, so that you don't end up getting e.g. HSL h. Or perhaps it could be user defined, via a setting (e.g. globalColorSpaces or something)

Last, I think that's totally fine to only implement for the get()/set() syntax. We don't want even more accessors to deal with.

[facelessuser]

What if we did this with coordinates too?
Ideally we'd want some way to specify the priority order, so that you don't end up getting e.g. > HSL h. Or perhaps it could be user defined, via a setting (e.g. globalColorSpaces or something)

All of this is way too "magic" for me.

I think looking for other spaces with hex is too magic as well. What if you have multiple spaces that define hex? Which one takes precedence? Sure it doesn't fail, but does it give you what you want? An error lets me know I tried to do something in the context of the space that's not allowed, that's a good thing because it makes me reconsider what I'm doing. If I don't care, then I can explicitly code it up to do some guessing.

I find it more frustrating when a library tries to guess what I want and gets it wrong because then I accidentally ship something that I think is working, but isn't actually, at least not how I intended it. Since Color.js is extensible, you can very likely end up with a situation with multiple hex, but sure, by default, that doesn't occur.

Something like intelligently guessing what c means is even more ambiguous. If some of this magic was disabled by default and you could opt-in I'd likely not care, but I just would never use it.

Anyway, that's just my 2 cents, others may disagree.

[LeaVerou]

All of this is way too "magic" for me.
[...]
I find it more frustrating when a library tries to guess what I want and gets it wrong because then I accidentally ship something that I think is working, but isn't actually, at least not how I intended it. Since Color.js is extensible, you can very likely end up with a situation with multiple hex, but sure, by default, that doesn't occur.

Fair point. As a general principle, I think magic can be great when it correctly predicts your intent, and terrible when it doesn't (which is why it's important to provide opt-outs, and ways to understand what is happening). When people say "too much magic", that often means that it guesses wrong too often and/or opting out is hard/impossible. But the alternative (no inference, everything is explicit) makes for interfaces that feel very tedious to use (such as having to remember to convert to sRGB every time you want a hex color because of the remote possibility another color space may define a format called hex).

Something like intelligently guessing what c means is even more ambiguous. If some of this magic was disabled by default and you could opt-in I'd likely not care, but I just would never use it.

That's basically what I proposed with the globalColorSpaces option (name TBB). It would be an array of color spaces (initially empty or containing only OKLCh) that are examined in priority order if looking up a colorspace-less coordinate fails, before producing an error. For the OOP API it could be a static property on Color, whereas for the procedural API, you'd import the array and fill it up.

[facelessuser]

Yeah, hex is generally less problematic.

If it is generally predictable in its behavior it may be okay. I do realize my opinion is subjective.

I can easily see myself working in Lab and forgetting to switch to LCh, but I get an OkLCh chroma. It makes sense enough, but it's not precisely what I wanted and I may not even realize it for some time and think I've calculated what I want. But if you can opt-out, that's okay too.

[LeaVerou]

I can easily see myself working in Lab and forgetting to switch to LCh, but I get an OkLCh chroma. It makes sense enough, but it's not precisely what I wanted and I may not even realize it for some time and think I've calculated what I want. But if you can opt-out, that's okay too.

Ooh that's a really good point. Perhaps the resolution should be dynamic, and take the working space into account. Hmmm. Will need to think more about this.

[facelessuser]

Yep, that's why I'm leary of such things. Sometimes all you care about is a best guess, and in those cases, if you have a great deal of tolerance, sure magic is fine. But when you have real, precise intent, a guess is simply not good enough and can actually be harmful if it doesn't know the context of your intent. In these cases, an explicit interface will protect you against such silly mistakes.