[css-color] Range of color parameters to the color() function is inconsistent

[faceless2]

Referring to example 9 at https://drafts.csswg.org/css-color/#icc-colors:

This example specifies four profiled colors: for a standard CMYK press, for a wide-gamut seven-ink printer, for ProPhoto RGB, and for the P3 standard RGB space.
color: color(swopc 0 206 190 77);
color: color(indigo 24 160 86 42 0 18 31);
color: color(prophoto 233 150 122);
color: color(p3 97 253 36);

The range of the parameters to the color() function is unclear. The examples show what appears to be a range of 0..255, for example color(prophoto 233 150 122), but this contrasts with the predefined spaces "srgb", "rec2020" and "image-p3", all of which have a range of 0..1.

A range from 0..1 is more natural for most colorspaces, or at least is more natural than 0..255. So I'm hoping that the examples simply need updating and should read more like color(prophoto 0.8 0.65 0.49). If this is the case then - although it's syntactic sugar - allowing a percentage as a synonym for 0..1 may be more natural, e.g. color(swopc 0 85% 70% 42%)

There will be spaces where 0..1 is inappropriate - I'm thinking specifically of Lab here. How this is handled would need to be discussed further, but for everything else, it's important to define the range consistently.

[svgeesus]

Good point. Yes, there are some examples which use incorrect 0..255 parameters in the color function; those need to be updated.
One reason we prefer 0..1 is that it is bit-depth neutral; displays are moving to 10 and even 12 bits per component.

[faceless2]

Thanks Chris. I should add that this (and the other css-color issues filed today) have come about as we implement css-color-4, which means we are butting up against the details.

[svgeesus]

Certainly good news that you are implementing! Feedback very welcome.

[tabatkins]

While the predefined ones do use numbers in the 0-1 range, there's no guarantee that color profiles from the outside will do so - that's just based on how they happen to be coded, right?

(I do support writing the examples to presume that they're written with the 0-1 range, to encourage good behavior.)

[Nadya678]

For me, the range 0..255 is more useful. The 0..255 range is used in rgb() and rgba(). Please look at the colour select in GIMP and MS Paint. I cannot have to convert it to 0..1 range specially for CSS.

[tabatkins]

Again, this isn't under our control; it depends on how the referenced color profile is defined. We can control how our predefined ones work, but it is much more natural to have them be 0-1; there's no reason to pretend they're an 8-bit number any more.

[svgeesus]

For me, the range 0..255 is more useful. The 0..255 range is used in rgb() and rgba(). Please look at the colour select in GIMP and MS Paint. I cannot have to convert it to 0..1 range specially for CSS.

0 to 255 is currently more common, yes, though that will change as 10 and 12 bit per component color becomes more widespread with the adoption of Wide Color Gamut (WCG) and High Dynamic Range (HDR); both of which require more bits.

Having to remember that 127, 511, and 2047 are all "half way through the code space" (at 8,10 and 12 bits per component) is less easy than the value in a bit-depth-neutral 0.0 to 1.0 space, which is simply 0.5.

MS Paint is not exactly setting the bar very high, and GIMP has supported 16 bit per component color for years now.

[svgeesus]

Responding to the original issue by @faceless2 the example which erroneously used 0 to 255 scaling has now been corrected to match the prose of the spec.

[svgeesus]

@faceless2 not wanting to lose your comment

allowing a percentage as a synonym for 0..1 may be more natural, e.g. color(swopc 0 85% 70% 42%)

will open a separate issue for that.