[css-color-5][mediaqueries-5] add <kelvin()> color-function and a means for exempting from global color filters

[elsiehupp]

Note:

This Issue covers two related feature proposals applying to two separate specification drafts. It may be preferable to split this into two separate Issues with links between them instead.

<kelvin()> color-function

Presently, the css-color-4 draft provides the color-function options <rgb()>, <rgba()>, <hsl()>, <hsla()>, <hwb()>, <lab()>, <lch()>, and <color()>. However, consumer lighting devices are increasingly marketed with the color specified in terms of the Kelvin temperature ("CCT") of a black-body radiator emitting that color of visible light. Kelvin temperature is a single scalar value, and the path of this value, the Planckian locus, can be mapped onto various color spaces using well-known formulas.

Software such as f.lux, redshift, and red-moon already provides (usually global) color filters for consumer video display devices.

A web designer or software developer may wish to assign a CCT color, but presently they would need to make use of an external algorithm to translate it into a value accepted by one of the existing CSS color-function options.

Note: while negative Kelvin temperatures do not physically exist, a negative color value passed to <kelvin()> could, for example, provide the inverse of the color provided by the same positive value, which could be useful for counteracting inherited color filters.

---

EDIT:

Because of the feasibility issues of implementing the second half of this Issue as a media feature, I’m reframing it in slightly different terms.

@uses-color-filter media-feature

For certain purposes, however, such as cinematic color grading, an end user may need certain visual elements to follow a defined color specification. Additionally, web designers and software developers may wish to offer color filters when a color filter is not already present.

In order to allow web designers and software developers to counteract an otherwise globally enabled color filter for certain visual elements or to offer local color filters in the absence of a globally enabled one, CSS could provide a media-feature with the <color> and <mix-blend-mode> values of any filters applied by the renderer or the system. This media-feature could be named something like @uses-color-filter.

There does not appear to be anything on this topic in the mediaqueries-5 draft, so I am basing this idea on the existing @prefers-color-scheme feature, thought it could also be analogous to the existing @color-gamut and @inverted-colors media features.

Provide a means for colors to request exemption from system color filters

For certain purposes, such as cinematic color grading, an end user may need certain visual elements to follow a defined color specification. Additionally, web designers and software developers may wish to offer color filters when a color filter is not already present.

From @Smilebags’ comment below:

One other concern I can see (I'm not sure whether this is either a non-issue or has already been solved, so I'm interested to find out) is that CCT is an absolute colour description. In sRGB, 6500 kelvin is essentially [1,1,1], but in another colour space (one with a white-point of D50, for example), the same 6500 kelvin has now changed 'colour', it would now be represented as something more blue than [1,1,1]. This might not be an issue if we always assume browsers are displaying colours with a D65 white point, but that might not be ideal. Again, I don't know enough about the existing and planned specs to know if this is actually an issue, so keen to hear what others think.

Therefore, the <color> specification could provide a means for requesting that the renderer use a neutral or absolute colorspace for a given specified color. As an example (from my comment below):

If the <kelvin()> function is specified as an accessibility aid, the specification might treat it differently than other <color> values. In so doing, browsers might treat <kelvin>() colors as absolute and counteract any operating-system-level white-point filter, though <color> values being specified as absolute vs dependent on operating-system-level white-point filters is probably a separate issue.

(Note that while I specifically focus on the <kelvin()> function, there might be design reasons for other colors to request exemption, and there might be design reasons for <kelvin()> colors to prefer inclusion rather than exemption.)

Basically, it should be an accessibility preference at the browser or system level whether websites or individual colors can specify an absolute white point and override any accessibility filters in place. This could help in the use cases of, e.g., cinematic color grading or professional photo editing, where certain color elements generally need to be calibrated as “accurate”, while other color elements (e.g. parts of the interface) generally don’t.

I’m not familiar enough with the CSS <color> specification to know to what extent it currently manages color spaces, so I can’t really propose a specific approach to addressing this particular functional issue.

[tabatkins]

I'm not sure how you intend the 'uses-color-filter' query to work - it sounds like you're saying it would reflect the actual value of the color filter the UA is applying, so the page author can counteract it if necessary? That won't really work in the context of MQs; precise values, particularly in multidimensional spaces like colors, don't really match with the query syntax that MQs expose, and you can't directly extract precise values from MQs (only whether a given query matches or not).

For example, screen widths work because they're single-axis, so we can meaningfully ask whether a given value is smaller or larger than the feature's value (but equality testing, like (width: 800px) is virtually worthless). Colors are three or four dimensional; there's no way for one color to be "less than" or "greater than" another.

[elsiehupp]

I did notice that the existing media queries only provided single scalar values. It could be possible to provide a the color filter color value as a single hex integer, though that isn’t entirely complete without the blending mode. What I’m suggesting in the second half of this issue might just not be possible under the current scope.

[elsiehupp]

The reason I thought of the <kelvin()> color-function is that I’m currently working on an SVG artwork of an explosion, and I thought it might be cool to be able to use actual black-body temperature values for this sort of thing. (Obviously artworks tend to be more stylized, though.)

[tabatkins]

Oh yeah, kelvin() isn't problematic at all; it's purely a question of whether it's worth providing in the spec.

[elsiehupp]

My thought is that it might be a useful convenience for some people, given the use cases I listed.

[Smilebags]

It would be pretty neat to be able to use kelvin values directly. That being said, I believe this could be fairly easily implemented in a library, instead of putting it into the spec. I can imagine it in something like PostCSS.

[elsiehupp]

For me, the main reason to put <kelvin()> directly into the spec is for those of us who don’t know how to use CSS libraries. (I learned HTML and CSS in middle school in an IDE on Windows 98 called “Under Construction 98” that is so old I literally can’t find any reference to it online, and I haven’t kept up with the various application stacks web developers use these days. About as modern as I get is WordPress and maybe Sphinx, and I kind of hate JavaScript.)

[Smilebags]

That's a great point. I also started building websites in notepad (without the ++), so can relate with the desire for minimal build tools.

I don't have any authority to say whether this should be in the spec or not, but I do feel like there are plenty of alternatives to get kelvin colours on a webpage. The burden of putting this in the spec is that every browser then needs to go out and build it, we hope they all get it right, and then if they either don't all implement it, or don't all do the same thing, we end up with a very hard to use feature.

One other concern I can see (I'm not sure whether this is either a non-issue or has already been solved, so I'm interested to find out) is that CCT is an absolute colour description. In sRGB, 6500 kelvin is essentially [1,1,1], but in another colour space (one with a white-point of D50, for example), the same 6500 kelvin has now changed 'colour', it would now be represented as something more blue than [1,1,1]. This might not be an issue if we always assume browsers are displaying colours with a D65 white point, but that might not be ideal. Again, I don't know enough about the existing and planned specs to know if this is actually an issue, so keen to hear what others think.

[elsiehupp]

Another reason for <kelvin()> to be in the spec (and implemented on the browser level) is indeed that it involves so many layers of translation, and the browser itself is in the best position to know, e.g., what the actual rendered colorspace is, so that, say 2700 kelvin (e.g. approximately an incandescent bulb at full brightness) actually ends up being rendered as 2700 kelvin.

Like, if there is an accessibility color filter (say, also 2700 kelvin) in use on the client operating system, should 2700 kelvin render “through” the color filter in order to still be 2700 kelvin? Or should the specified 2700 kelvin itself have its white point be shifted by the color filter and render as something else?

If the <kelvin()> function is specified as an accessibility aid, the specification might treat it differently than other <color> values. In so doing, browsers might treat <kelvin>() colors as absolute and counteract any operating-system-level white-point filter, though <color> values being specified as absolute vs dependent on operating-system-level white-point filters is probably a separate issue. (This issue kind of achieves the same purpose as the second part of my initial issue, just by different means, without exposing this information to the website. I can edit the above text to reflect this.)

Basically, it should be an accessibility preference at the browser or system level whether websites or individual colors can specify an absolute white point and override any accessibility filters in place. This could help in the use cases of, e.g., cinematic color grading or professional photo editing, where certain color elements generally need to be calibrated as “accurate”, while other color elements (e.g. parts of the interface) generally don’t.

[elsiehupp]

I just edited the main Issue text. (It doesn’t show up in the comment timeline, so I’m mentioning it here.)

[svgeesus]

kelvin() can only produce colors on the Planckian (black-body) locus. Note that neither D50 nor D65 are on this locus (nor is the whitepoint used by DCI-P3 or by ACEScc, for example). This is why the term correlated color temperature exists, to relate a given white color to the closest Planckian locus point.

Although perhaps, you want to re-grade an entire image to a new white point? It wasn't clear exactly what you were proposing.

[elsiehupp]

Re @svgeesus—I honestly don’t understand the particular details of color correlation, and my updated description is based on what @Smilebags commented. Or are you responding to him and not to me?

Regarding re-grading, I think that’s what I was referring to as “color filter”. While the phrase may not be technically accurate, I used a deliberately general term because not all global color filters are used for Kelvin color temperatures. For example, macOS and iOS also offer colorblindness filters as well as color-tinting filters, which are separate from Apple's “Night Shift”.

[svgeesus]

Still not sure I entirely understand this proposal, but as it seems to relate to color modification functions I am re-tagging it to CSS Color 5 which seems a better fit than 4.

[tabatkins]

It's not a color modifier, just a new color-producing function that references the black-body radiation spectrum. That said, fine to move to Color 5.

[svgeesus]

CCT is an absolute colour description.

Almost. The series of CIE Daylight standards are absolute color descriptions, yes.

The daylight standards are not actually on the black body locus, but somewhat close to it. A whole set of colors can be on the line between 6504 on the black-body locus and D65 and these will all have a CCT of 6504 but they will be different colors (varying in a magenta to green direction).

But anyway, D65 is a absolute color description whose chromaticity coordinates are fixed.

In sRGB, 6500 kelvin is essentially [1,1,1], but in another colour space (one with a white-point of D50, for example), the same 6500 kelvin has now changed 'colour',

No, the color hasn't changed. As you said, or were I think trying to say, D65 is an absolute color.

it would now be represented as something more blue than [1,1,1].

It has changed representation, because it is now in a different colorspace. But it is the same color.

[svgeesus]

It's not a color modifier, just a new color-producing function that references the black-body radiation spectrum.

It seems not, because

Software such as f.lux, redshift, and red-moon already provides (usually global) color filters for consumer video display devices.

A web designer or software developer may wish to assign a CCT color

So I think what is being asked for is a way to calculate corresponding colors when the adapted white has changed. In other words, chromatic adaptation.

[elsiehupp]

Hi @svgeesus—

I could imagine multiple possible use cases for a <kelvin()> color-function. While, yes, one web designer might want to create a chromatic adaptation, a different web designer might want to use a color in its absolute state, and yet another web designer might want to use it as an input for some as yet unforeseen function.

If CCT chromatic adaptation can be easily produced using the absolute color value (from <kelvin()>) and one or more existing blend modes, it might be unnecessary to create a new “white balance” blend-mode function exclusively for the purpose of chromatic adaptation. On the other hand, an explicit “white balance” function (or set of functions) might still be a welcome convenience for some designers.

The main reason I suggest the <kelvin()> color-function itself as a convenience is that Kelvin color values are increasingly used in marketing materials (for LED luminaires), so designers might increasingly be thinking in those terms, rather than exclusively in the terms of pixel color values, pigment color values, etc.; and the math for translating a Kelvin blackbody locus to the color on a computer display is well enough established that it should be relatively trivial for browser vendors to implement.

[svgeesus]

Chromatic adaptation relates to the state of someone's eye, in other words what color they currently consider to be a neutral white. This is not something a web designer can control.

The main reason I suggest the <kelvin()> color-function itself as a convenience is that Kelvin color values are increasingly used in marketing materials (for LED luminaires),

A range of different colors (varying along the green-to-magenta tint axis) will have the same CCT.

the math for translating a Kelvin blackbody locus to the color on a computer display is well enough established that it should be relatively trivial for browser vendors to implement.

For a color exactly on the black body locus, yes. That won't necessarily get you the same color as that produced by a random lightbulb that is labelled with the same CCT. As an example, D65 white is not the same color as a blackbody 6504 Kelvin.

And display of those colors assumes adaptation to D65, not the white produced by that bulb.

[svgeesus]

Moving new feature requests to CSS Color 6, to stabilize CSS Color 5 which is about ready to move to CR.

[elsiehupp]

@svgeesus—regarding the various ambiguities in translating between CCT and RGB, etc., perhaps I should clarify that what I am suggesting here is a means to match white balance to two possible reference points:

1. Operating system white balance, e.g. iOS Night Shift and True Tone; and
2. Luminaire white balance, e.g. Hue.

Both of these encapsulate a number of assumptions, and I'm not really in a position to defend any of them so much as to suggest accommodating them, warts and all.

Some example references for the above might include:

1. Redshift, an open-source utility similar in function to the closed-source F.lux, which discusses its assumptions in the document README-colorramp.
2. The Matter specification, which represents a kind of consensus for "smart home" devices, including color-programmable luminaires. According to the Matter 1.0 Application Cluster Specification (page 111) it uses the CIE 1931 color space. (I don't know how CSS approaches display color spaces more generally, though.)

Again, what I am suggesting here is allowing web developers to employ similar assumptions to those used by existing implementations, though the assumptions should of course be explicitly enumerated.