Color.js is very error-happy

[LeaVerou]

While errors are nicely informative, this makes it annoying to develop UIs that use it (including components), where there are often intermediate states with incorrect values (e.g. a user is in the middle of typing a color, or a color channel is set before the color space is).

Case in point that finally prompted me to post an issue: this PR

For things like the color constructor, throwing makes sense and is helpful. But e.g. does it make sense here?

• https://github.com/color-js/color.js/blob/main/src/getColor.js#L16 (can easily happen as an intermediate state)
• https://github.com/color-js/color.js/blob/d49b1ae0a571f700dd09aa777da595d681b1d17b/src/space.js#L268 (can easily happen when multiple modules register the same color space from different URLs)
• Getting a coordinate: https://github.com/color-js/color.js/blob/main/src/get.js#L8 via https://github.com/color-js/color.js/blob/main/src/space.js#L349

Perhaps we should have some kind of opt-in mode for these errors? Or just warn? A warning serves the same purpose, and is less disruptive to calling code.

[ghost]

If you don't mind me chiming in. While there exist methods such as CSS.supports('color', yourQuestionableColor) I found that various color values would produce a true without being parsable. Something like isValid/canParse would surely be a big help here. Unfortunately Colorjs is currently wired to immediatly throw errors if a color fails to parse. Would you recommend i need to write this into a promise to avoid this problem?