[css-color-5] What are the color functions (or color adjusters)?

[jonathantneal]

1. The css-color-5 specification makes references to <color-functions>. Would these functions include the lightness adjuster in Example 10? If not, what are those adjusters to be referred to as?

2. Where might I find a definitive list of those adjusters?

   1. The css-color-4 specification has a somewhat related and entertaining entry:

    
   The color-functions are , ,
   , , , , , , and .
    

3. Are the adjusters as follows?

   • lightness, a, and b within the LAB color space;
   • lightness, chroma, and hue within the LCH color space;
   • hue, saturation, and lightness within HSL color space; and,
   • red, green, and blue within the RGB or SRGB color space.

4. UPDATE: I realize now that HSL also uses lightness and does not use luminance (see comment history). If I explicitly set my colorspace to rgb and then adjust lightness() does it — A. permanently move me to the LCH colorspace; B. temporarily move me to the LCH colorspace to perform the adjustment and then move me back; C. fail; D. something else? I think it matters, because I would want to know what the computed value should be when this is natively supports, and because I would want to write a polyfill that followed that same expectation as closely as possible.

[svgeesus]

1. Yes, I just opened that issue today before seeing this issue.

2a. The bikeshed source is

The <dfn export>color-functions</dfn> are <rgb()>, <rgba()>,
		<hsl()>, <hsla()>, <hwb()>,
		<lab()>, <lch()>,
		<color()>, and <device-cmyk()>.

This is supposed to auto-link to their definitions, but doesn't.

2b. In Una's proposal, those would correspond to colorspace, and color-function is undefined, which is why I opened #4747 so they can be correctly defined

2c. Bikeshed autolinking currently works well when one spec links to another, but only the latest version of each spec is linked to, by design. Unfortunately that means that color-5 can't link to color-4 which is an issue holding back first publication of color-5 (and several other specifications). @fantasai is working on a patch to bikeshed to allow this.

3. Yes. Also, adjusters is a better and less overloaded term than color-function which has a definition in CSS Color 4 (and an expanded definition in CSS Color 5, which allows relative color functions).

4a. In @una proposal the default colorspace is lch and so lightness, chroma and hue are available.

4b. The appropriate ones are available if you switch colorspace (and colors are first converted tothat colorspace before manipulation). So for example if the colorspace is set to hsl then the colors all get converted to sRGB and then a hue manipulation will work on HSL hue.

4c. If you use an unavailable adjuster then the colorspace should auto-convert to the one that has this adjuster. So using chroma would auto-conver to LCH.

4d. Need to define what happens if you use hue or lightness in, say, rgb where there isn't an obvious default to convert to. That might be disambiguated by picking distinct names (at the expense of verbosity) or by saying it always goes to LCH since that is the default anyway.

[svgeesus]

4c. If you use an unavailable adjuster then the colorspace should auto-convert to the one that has this adjuster. So using chroma would auto-convert to LCH.

4d. Need to define what happens if you use hue or lightness in, say, rgb where there isn't an obvious default to convert to. That might be disambiguated by picking distinct names (at the expense of verbosity) or by saying it always goes to LCH since that is the default anyway.

For now, I went for the simpler option where the color-adjusters available depend on the colorspace. So if you want to adjust HSL hue (for example to port something you already have in sass) then you must specify hsl as the colorspace. Being explicit looks more easy to understand and more maintainable (if other colorspaces are added in the future) rather than messy "if you ask for saturation it autoconverts to HSL but if you ask for Hue it autoconverts to LCH because reasons" heuristics.

[svgeesus]

Color-adjuster is now a defined term and is used in the grammar.

Colorspace is also a defined term and (like the examples, but unlike what the grammar used to say) doesn't require the trailing (). So you say lab not lab(). Also, you can now say xyz as well.

I added an example of adjusting in xyz to show color mixing in linear-light space.

[svgeesus]

I don't think adjusting individual x,y,z channels is particularly useful. Adjusting all three at once is (multiply all of x,y and z by 0.9 and the color darkens but keeps the same chroma and hue, for example) but I left it in just in case someone wants to go crazy and define their own chromatic adaptation transform or something.
Although, the built-in adjusters wouldn't let you do that, it would need calc.

[una]

Thanks, @svgeesus for adding color-adjuster. I agree with keeping it simple where the color space is defined.

For the hue-adjuster I'm a little confused about the increasing/decreasing longer/shorter syntax. Would this be color space dependent?

[svgeesus]

For the hue-adjuster I'm a little confused about the increasing/decreasing longer/shorter syntax. Would this be color space dependent?

It would only apply to those color spaces which have a hue angle, like LCH, HSL, HWB. Check out example 4 and example 5 which show the shorter and longer path respectively. Hope the diagrams explain this?

[svgeesus]

@jonathantneal do the recent spec edits resolve your issue?

[jonathantneal]

Those examples help, as did your initial comment, and I think this is resolved, with a need to apply this knowledge to my own work. Thank you, @svgeesus, for your help, your patience, and your excellent follow through.

In both levity and seriousness; I hope I will be a developer like you when I grow up.