svgeesus
commented
7 years ago Firstly, the color adjustment part of CSS Color 4 is speculative and has not been widely reviewed. it is likely to change. Given that, yes, it was written before CIE-based colors were added to the spec and thus, uses HSL as the computational space. This has obvious problems due to the discontinuity, non-linearity and non-perceptual-uniformity properties of HSL (and also results in clipping for colors outside the sRGB gamut).
You are correct that allowing computations to be done in LCH(ab) space would be more perceptually uniform (and also would not suffer from clipping).
It is incorrect that Lab does not have a measure of saturation. The formula is simply s = C / L
Thus on a CIE Lab diagram, lines of constant chroma are parallel to the central L axis while lines of constant saturation form a cone whose apex is the black point.
Luv is much less widely used nowadays compared to Lab. I forget why (and am currently traveling so my color science books are not to hand, so I can't explain why at present).
gasrios
Section 14 of “CSS Color Module Level 4” (https://drafts.csswg.org/css-color/#modifying-colors) defines two color adjusters, “saturation” and “lightness”, “when base color is interpreted as an HSL”.
While HSL is more intuitive to use than RGB when transforming a color, it is also perceptually non-uniform: for example, a human observer will not perceive “hsl(0deg 100% 50%)” (red) and “hsl(240deg 100% 50%)” (blue) to have the same levels of lightness and saturation. Perceptually uniform color spaces like CIELab do not have this problem, but the spec does not define color adjusters for them.
If the spec supports transformations like “color-mod(lab(50, 80, 67), saturation(-10%))” or “color-mod(lch(50, 100, 40), lightness(-10%)), saturation(-10%))” by first converting the color specified in LCH to HSL, there is no guarantee the resulting color will have the desired appearance.
Would it make sense to overload the color adjusters “saturation” and “lightness” so they support different transformations for perceptually uniform and non-uniform color spaces?
If so, there is another problem: CIELab has no saturation definition, so there is no correct way to handle the associated color adjuster in it. Furthermore, as “chroma” and “lightness” are not independent from one another (CIE defines “chroma” as “colorfulness of an area judged as a proportion of the brightness of a similarly illuminated area that appears white or highly transmitting”), changes in lightness will also affect the saturation of a color, and this cannot be corrected in a color space that does not formally define saturation.
One alternative would be to add support to CIELuv, which defines saturation, and handle the perceptually uniform color adjusters using this color space. CIELuv also has a cylindrical representation, therefore the perceptually uniform color adjusters can be trivially defined in it.
The only point of attention is, as stated above, to remember that changes in lightness must be reflected in chroma (”colorfulness of an area judged as a proportion of the brightness of a similarly illuminated area that appears white or highly transmitting”), so saturation (“colourfulness of an area judged in proportion to its brightness”) remains unchanged.