CSSColorValue.colorSpace restricts naming of future color functions and color() keywords

[tabatkins]

CSSColorValue exposes a .colorSpace attribute and a .to(colorSpace) method, which use the same set of strings. For color() functions, the corresponding string is the color space keyword; for the other color functions, the corresponding string is the function name.

These two sets of names aren't guaranteed to be distinct! Currently, there's no overlap, but there was in a previous revision to the spec when color(lab ...) was allowed.

@svgeesus and @LeaVerou, do you think restricting these two sets to be non-overlapping in the future is reasonable? Or do you think it's plausible we may want to have such an overlap? If the latter, I think the easiest solution for this is to use parens at the end of the string for the function names, so CSSRGB.colorSpace would return "rgb()", you'd call c.to("rgb()"), etc. Thoughts?

[LeaVerou]

Yeah we keep going back and forth about which or even whether color functions should be representable in color().

But let's step back for a bit.

Do we actually need a .to(colorSpace) method in CSSColorValue? It cannot actually convert in many cases (e.g when values contain variables or relative values of some sort), and I believe was added as a stopgap before we resolved to have a separate Color class. I think conversions make more sense to be handled by the Color class, which would only accept resolved values and thus wouldn't have the problem of only being able to convert sometimes. It will be more verbose, but I think the predictability is worth it.

[svgeesus]

For color() functions, the corresponding string is the color space keyword; for the other color functions, the corresponding string is the function name.

This follows naturally from the design decision in Typed OM that retaining and exposing the syntax is the most important thing (thus, lots of different ways to specify an sRGB color), while in the Color object exposing the values and the colorspace is the key thing. And thus, conversion to sRGB in the Color object does not need to have options to pick which of the many syntaxes you get.

I agree with Lea that handling color conversions based on fully resolved values in the Color class makes more sense.

[tabatkins]

I've let this sit overnight, and I think I can agree with y'all. Assuming work continues on Color, I can see dropping the .to() function, and then moving .colorSpace to the CSSColor subclass where it's still needed. We can always revisit if necessary in the future.

That'll make this issue moot, then. Thanks!

[LeaVerou]

Assuming work continues on Color

Chris and I definitely intend to continue working on it (for me as time allows, unless I can get sponsorship for this work), but I will point out you can also pitch in to the work as a co-editor 😉

[tabatkins]

If I had the time to work on everything I had interest in....

[LeaVerou]

If I had the time to work on everything I had interest in....

I know the feeling 😕