How should angle coordinates be handled in nonstandard color spaces

[lloydk]

Continuing a discussion started in #435

The hsluv, hpluv, lchuv and hct color spaces currently allow angle units for their angle coordinate. As mentioned here this isn't spec compliant.

Do we need to change the coordGrammar to only allow <number | percentage> for the angle coordinate?

[facelessuser]

Personally, I would at least like to see percentages of non-standard colors in the color() format support defined ranges for percentages. Non-standard colors are not all confined to 0 - 1, and with things like hues, I would think a percentage should cover 0 - 360. At least that is how I've implemented them in my own color library.

[LeaVerou]

I would love to hear from @svgeesus on this.

[facelessuser]

Based on the recent HDR spec update by @svgeesus, it seems like JzCzhz will support full <hue> support for the angle property: https://drafts.csswg.org/css-color-hdr/#color-function. Unless I'm misunderstanding something.

It sounds like that would answer the question about angles. They will not support percentages and will instead support hues as done everywhere else. This probably makes the most sense for consistency, so I'm actually fine with this.

[LeaVerou]

@facelessuser For predefined color spaces we can define whatever, the question is for custom color spaces, where the options are:

1. Either we allow <hue> for every coordinate
2. Or, we disallow <hue> more generally
3. Or, we give authors a way to specify a coord grammar (making the color() IACVT if it doesn't match it).

Neither of these are ideal, hence my question.

[facelessuser]

If predefined spaces in the color format have coord specific grammar, I think custom spaces should be able to tap into that as well. If not, it makes the interface confusing. That is my personal opinion though.

[facelessuser]

CSS may not allow custom polar systems or arbitrary, non rgb color spaces, but this library does, I think there should be consistency for the user. That is my main point.

If CSS were to extend the color format in the same way that this library does, then I'd probably argue the same for CSS, but it doesn't sound like there is intention to do that currently.

I don't think it helps that angles would be treated one way for a predefined space but not for others, I think it would just confuse users.

I also don't think that spaces that are not confined to ranges of 0 - 1 should have percentages that map to those ranges as it makes its functionality useless; it'd be better to just not allow percentages if their isn't some utility in them.

[lloydk]

CSS may not allow custom polar systems or arbitrary, non rgb color spaces, but this library does, I think there should be consistency for the user. That is my main point.

This is my feeling as well.

I also don't think that spaces that are not confined to ranges of 0 - 1 should have percentages that map to those ranges as it makes its functionality useless; it'd be better to just not allow percentages if their isn't some utility in them.

<percentage> does allow for ranges other than 0 - 1. For example luv has reference ranges of -215 - 215 and has this coordGrammar:

"<number> | <percentage>", "<number> | <percentage>[-1,1]", "<number> | <percentage>[-1,1]"

[facelessuser]

does allow for ranges other than 0 - 1. For example luv has reference ranges of -215 - 215 and has this coordGrammar:

Okay, that's great then.

[svgeesus]

Based on the recent HDR spec update by @svgeesus, it seems like JzCzhz will support full <hue> support for the angle property: https://drafts.csswg.org/css-color-hdr/#color-function. Unless I'm misunderstanding something.

It sounds like that would answer the question about angles. They will not support percentages and will instead support hues as done everywhere else. This probably makes the most sense for consistency, so I'm actually fine with this.

That is correct (and is the main reason to add JzCzHz, as the only polar HDR color space) and thus forms a precedent to use for custom color spaces.

Currently in CSS Color 5, custom color spaces can only be defined by referencing an ICC.1 profile and thus, cannot use a polar form (they all relate to either XYZ-D50 or CIE Lab (D50) as profile connection space) so the grammar does not currently allow a hue angle. Also, to date that option is only of interest to the CSS-to-PDF market, (for CMYK and friends) the browsers seem content to ignore ICC profiles for custom colors although they use them in images.

It would be good to allow custom (additive) colorspaces in CSS Color 5 to be defined in terms of primary chromaticities, whitepoint and transfer function; and in that case it would also make sense to allow a polar form. But no-one seems in a rush to implement that. So a CSS-like setrialization of spaced supported by color.js is currently out of spec.