- From: Lea Verou <notifications@github.com>
- Date: Wed, 15 Feb 2023 07:53:14 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 15 February 2023 15:53:26 UTC
This issue came up when designing the Color API: https://github.com/WICG/color-api/issues/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? -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/discussions/817 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/repo-discussions/817@github.com>
Received on Wednesday, 15 February 2023 15:53:26 UTC