search

color-js / color.js

Color conversion & manipulation library by the editors of the CSS Color specifications
https://colorjs.io
MIT License
1.93k stars 81 forks source link

How should angle coordinates be handled in nonstandard color spaces #442

Open lloydk opened 9 months ago

lloydk commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

I would love to hear from @svgeesus on this.

facelessuser commented 9 months ago

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 commented 9 months ago

@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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago
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 commented 9 months ago

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.