Exposing predefined instances of an object as static properties on the class

[LeaVerou]

This issue came up when designing the Color API: WICG/color-api#33

The ColorSpace class involves some predefined color spaces that will be created and registered by the browser (srgb, hsl, hwb, lab, lch, oklab, oklch, xyz, xyz-d65, display-p3, rec2020, prophoto, a98rgb).
It is convenient to make them available to authors. Right now there is ColorSpace.get(id) which returns a ColorSpace object from the id it's registered with, and that can be used with the predefined color spaces as well (e.g. ColorSpace.get("lch")).

We were wondering about also exposing these color spaces as static properties on ColorSpace, for convenience (e.g. ColorSpace.lch. However, I’m a bit worried about polluting the namespace with an unknown number of properties (known right now, but these will expand in the future), and I wonder if they should be on a separate object, which itself hangs on ColorSpace.

Is there any precedent in the web platform that we could look at?

[annevk]

If you already have get() and a constructor I would wait a bit to see what people end up doing with it. With APIs it's usually good to start out small and then expand based on usage and library patterns.

[domenic]

Based on https://source.chromium.org/search?q=file:%5C.idl%20%22static%20readonly%20attribute%22&ss=chromium I'm not aware of any precedent for this on the web platform, or at least the parts of the web platform currently implemented in Chromium.

I don't envy whoever has to figure out how https://w3ctag.github.io/design-principles/#casing-rules applies to these, especially things like xyz-d65 or a98rgb :).

[LeaVerou]

Thank you!

I don't envy whoever has to figure out how w3ctag.github.io/design-principles/#casing-rules applies to these, especially things like xyz-d65 or a98rgb :).

Yeah, that is yet another reason to not do this, lol 😅