What to do with serialization of author-defined color spaces?

[LeaVerou]

We should really decide what to do with parsing and serialization.
For color spaces that are supported by CSS, this is easy: it should parse all CSS formats (through CSSColorValue internally) and serialize to a supported CSS value. Even for built-in color spaces it's still nice if the behavior is expressed using the same primitives as author-provided color spaces.

But what to do with author-defined color spaces? They still need to serialize somehow.

From #23 (comment) :

If I understand correctly, new ColorSpace("hsv") will make it into the <color> CSS type either as color(§hsv h s v / alpha) (with the § to be defined) or color(--hsv h s v / alpha) (with the plumbing between Color API and @color-profile to be defined).

The HSV example in the README also hints at the idea of a custom serialization (e.g. hsv(h s v / alpha)), which would require a parse counterpart to call on values found wherever the <color> CSS type is expected, but this kind of unrestrained color syntax sounds very complex.

What we do in Color.js is that each color space may provide parse and stringify methods, and if it doesn't, the default serialization is color(colorSpace ...coords / alpha), whether it produces a valid CSS color or not.
I think that may work here too. The idea of producing invalid colors doesn't make me too happy, but given these color spaces are not supported by CSS yet, there's no way to serialize them into a valid color anyway.
Maybe we should make it obvious that they are not valid CSS colors by prepending their color space id with something?
But what if Color API is used to polyfill color spaces that browsers don't natively support yet but are actually in the spec?

[tabatkins]

The question to be answered first is what the purpose of serializing is. If it's just another way of representing the color, similar to toJSON(), then just emitting something that includes the author colorspace is fine.

But if it's to produce a string that can be used in CSS and other web-platform things that rely on CSS colors, then we need to be sure to only emit strings that are valid CSS. That probably means we need to walk up the color space tree until we find a space that we do know how to serialize into a valid CSS value.

This implies that different browsers can produce different serializations, if the set of color spaces they support in CSS is different.

[tabatkins]

If we introduce ways to plumb author-defined spaces into CSS, then we can stop at those instead of only searching for browser-recognized spaces, of course.

[LeaVerou]

Thinking about this some more, I think we should separate out the Color object serialization (color.toString() method) with serving the use case of getting a color that can be used in CSS (perhaps a toCSSValue() method? Or toCSS()).

In color spaces that are natively supported in CSS, such as the built-in ones, these could return the same thing. In custom color spaces, or anonymous color spaces, toCSSValue() would need to be part of the ColorSpace spec to do something custom, otherwise the browser would convert to parent color space and call its own toCSSValue() method (eventually we'll reach a color space that implements toCSSValue()` because all the native ones do).

Perhaps we could even have additional sugar: colorSpace.toCSSValue() would call colorSpaceSpec.toCSSValue(), then pass the result through CSS.supports("color", result) and if it's not supported, do the thing with converting to the parent color space.

(I have mistyped toCSSValue() as toCSS() enough times in this comment that I think it should probably be the latter)

Thoughts, @svgeesus @tabatkins ?