Add missing formats to color spaces

[lloydk]

Some color spaces couldn't be parsed because they didn't have any formats.

Added formats for:

• a98rgb-linear
• p3-linear
• prophoto-linear
• xyz-abs-d65

I used a dashed-ident for all of the spaces above similar to #430.

[netlify]

✅ Deploy Preview for colorjs ready!

Name	Link
🔨 Latest commit	1e984e1
🔍 Latest deploy log	https://app.netlify.com/sites/colorjs/deploys/65cc26103892380008aa4876
😎 Deploy Preview	https://deploy-preview-435--colorjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[LeaVerou]

Hey, thanks for working on this!

In general, as an API Design principle, I think boilerplate should be avoided. It makes for annoying DX, increases the chance of errors, and makes it harder to change things. Software is much better than humans at generating repetitive structures; therefore any boilerplate needed should be generated automatically by the software.

How dies this apply here? So, I think we should handle this a bit differently (which is how I thought it was handled, and maybe it was and it broke at some point): Every color space, automatically, gets a color() format supporting a dashed ident and/or ident for the color name plus <number> | <percentage> for the coords (or <percentage> | , I'm fine either way). Authors can still specify color` formats explicitly, and they will override this but we should not risk having color spaces with no formats because an author forgot to include this.

What do you think?

[lloydk]

How dies this apply here? So, I think we should handle this a bit differently (which is how I thought it was handled, and maybe it was and it broke at some point): Every color space, automatically, gets a color() format supporting a dashed ident and/or ident for the color name plus <number> | <percentage> for the coords (or <percentage> | ``, I'm fine either way). Authors can still specify color` formats explicitly, and they will override this but we should not risk having color spaces with no formats because an author forgot to include this.

That's similar to an idea I've had for a while which is the coordGrammer for most spaces could be generated from the coordinate metadata. So in addition to number or percentage angle coordinates would also be supported in the auto generated color format.

[LeaVerou]

That's similar to an idea I've had for a while which is the coordGrammer for most spaces could be generated from the coordinate metadata. So in addition to number or percentage angle coordinates would also be supported in the auto generated color format.

That would not be spec compliant as it's unlikely for color() to ever support angles. I think for spaces that need angles, it makes more sense to have dedicated functions (potentially prefixed? Not sure).

[lloydk]

That's similar to an idea I've had for a while which is the coordGrammer for most spaces could be generated from the coordinate metadata. So in addition to number or percentage angle coordinates would also be supported in the auto generated color format.

That would not be spec compliant as it's unlikely for color() to ever support angles. I think for spaces that need angles, it makes more sense to have dedicated functions (potentially prefixed? Not sure).

We allow a coordGrammar to be specified for the color function (#370) and a number of color spaces that aren't a part of CSS (hpluv, hsluv, lchuv, hct) allow angle units for their angle coordinates. Should those spaces be changed to only allow number and percentage?

[LeaVerou]

@lloydk I think so (together with a custom function), but we should discuss in a new issue.

[lloydk]

@lloydk I think so (together with a custom function), but we should discuss in a new issue.

Created a new issue #442

[jgerigmeyer]

Closed, replaced by #439.