[css-typed-om] `toColor()` intentionally restricted to predefined colors?

[svgeesus]

In 4.6 CSSColorValue objects, the toColor(colorspace) method states:

2. If colorspace’s value is not one of the predefined colorspaces, throw a SyntaxError.

However, in CSS Color 4, the syntax of the color() function is:

<pre class='prod'>
	<dfn>color()</dfn> = color( [<<ident>> | <<dashed-ident>>] [ <<number-percentage>>+ ] [ / <<alpha-value>> ]? )
</pre>

while currently, CSSColorValue only handles the <ident> case and not the <dashed-ident> case.

Is this an intentional restriction, or an oversight? If intentional, what is the rationale?

[tabatkins]

Currently intentional, but intended to be temporary.

Basically, I'm not sure how to handle the reference to a custom space when doing color conversion (to or from CSSColor). This is a somewhat generic problem with CSS-based references vs JS - in CSS references are defined on a per-tree basis (so shadows don't interact with each other, and can theoretically have same-name references without colliding), but JS stretches across trees, so it's not clear where it should be grabbing the ref from.

(I know that I'm inconsistent here - the other conversion functions don't check that a CSSColor value is using a predefined space. They should, and throw in that case.)

Note that you can directly create a CSSColor in a custom colorspace, so you can still use it in CSS; you just can't convert it to other spaces.

My vague plan is to let people provide a Document/ShadowRoot reference to the conversion functions, and have it draw on that to figure out the definition of the custom colorspace. (And use the same strategy for other cases across CSS that run into the same problem.)

[svgeesus]

Closed by

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