Exposing predefined ColorSpace objects as static properties on ColorSpace?

[LeaVerou]

@tabatkins suggested we should the predefined color spaces as static properties on ColorSpace. We may instead want to expose them on a sub-object, to avoid polluting ColorSpace as a namespace.

Btw the spec should also include an appendix with example code for the predefined (Color 4) color spaces.

[tabatkins]

I don't understand "polluting the namespace". Do we really think we're likely to have predefined colorspaces with names that clash with methods/attributes we want on ColorSpace? That seems pretty unlikely, from the current set.

[LeaVerou]

It's unlikely, but can you guarantee there will never be such a conflict?
Also, it's unclear what something like ColorSpace.foo means.

I don't have a strong opinion, just some second thoughts.

[tabatkins]

It's unlikely, but can you guarantee there will never be such a conflict?

Of course not, but we don't deal in absolutes, and we can just tweak names as necessary. But I find it exceedingly unlikely that a predefined colorspace (with the names coming from industry, generally) will overlap with the sort of method and attribute names we'll be using here.

Also, it's unclear what something like ColorSpace.foo means.

I think it's pretty clear that ColorSpace.a98RGB means "the a98-rgb color space". I literally can't come up with a clearer, more straightforward way to express that.

[LeaVerou]

I think after reading the responses in w3ctag/design-reviews#817 I’m leaning towards that we shouldn't do this in L1.