[css-color-4] Achromatic colors converted to hue-ish spaces should treat hue as "missing", not NaN

[tabatkins]

In https://drafts.csswg.org/css-color-4/#hue-syntax it's stated that:

For colors very close to the neutral axis, the hue angle becomes indeterminate (for example, in Lab, minute changes in near-zero a and b values give huge changes in LCH hue angle). Therefore, sometimes a hue angle of NaN (not a number) may be returned.

Then this is later referenced in interpolation:

If one of the angles has the value NaN, then for interpolation, NaN is replaced by the value of the other hue angle. If both angles have the value NaN, then for interpolation, NaN is replaced by the value 0 for both angles.

The intent of this spec text is good and correct; it means interpolating from gray to green in LCH just becomes greener, rather than the hue swinging from red to green or something.

However, the exact mechanics of this aren't workable. NaN is limited to existing within the bounds of a calculation; it gets censored to infinity if it would escape (and infinity then gets clamped to the actual largest value the impl supports). So we can't have a NaN value just hanging out in normal CSS values. I think instead this should be phrased as achromatic colors having a "missing" hue, and then interpolation can key off of whether the hue is "missing".

Even if NaN did persist into normal CSS values, I don't think we actually want to merge "calculation for the angle yields NaN" with "achromatic color interpolates with chromatic color"; the latter is a common non-error case with an obvious solution, while the former is explicitly the result of a bad or nonsensical calculation with no obvious answer. So we really shouldn't be keying off of NaN anyway; a "real" NaN should be treated the same as an infinity (which it luckily censors itself into already), where it's an error case that just has an arbitrary answer (per #6105, effectively 0deg).

[svgeesus]

If a top-level calculation (a math function not nested inside of another math function) would produce a value whose numeric part is NaN, it instead act as though the numeric part is +∞.

and

a "real" NaN should be treated the same as an infinity

What I'm not seeing is

a) an explanation of why that spec text is a good and useful thing (divide by zero produces infinity or -infinity, not NaN)
b) how the value "missing" is supposed to be passed around in an API which has number, float or double parameters. Obviously it can be represented textually in CSS syntax, or in the (string-based) CSS OM but how can it

Several color APIs use NaN here (d3.js for example, which also uses it for missing data in general, colorio and color.js too. It seems natural that the Color API would do this too.

So first we need to understand why CSS V&U wants to map NaN to +∞.

I see @LeaVerou asked a similar question earlier

I don't understand the sentence "it produces a NaN, which is censored into an infinity". Mathematically, 0/0 does not tend to infinity and is an indeterminate form.

A quick search for NaN in V&U4 issues didn't turn up any motivation for this strange censoring.

[LeaVerou]

It should be noted that there is a lot of prior art in Color libraries for using NaN for achromatic interpolation.

NaN is limited to existing within the bounds of a calculation; it gets censored to infinity if it would escape (and infinity then gets clamped to the actual largest value the impl supports).

That ...seems like hugely problematic behavior that we should, at the very least, get group consensus on before we accept it as something to design other specs around. NaN is conceptually completely different from Infinity.

[tabatkins]

an explanation of why that spec text is a good and useful thing

Because NaN is a meaningless error state. Rather than putting the onus on every single function and property that accepts numeric values to define how they handle a NaN, censoring it immediately gives us a well-defined behavior. And, since you only produce NaN via writing erroneous code, the actual behavior doesn't much matter anyway; it just needs to be well-defined, and ideally it makes it somewhat obvious that something is wrong. infinity accomplishes both of those goals.

how the value "missing" is supposed to be passed around in an API which has number, float or double parameters.

That's quite a different question from what the spec is currently concerning itself with! Right now, this "missing hue" situation is solely caused by interpolation in a hue-ful space, when an achromatic color is originally defined in a hue-less space. It never shows up in a way that actually gets exposed to users, since the intermediate interpolation has a well-defined hue at all times.

If you want this state to be explicitly specifiable by userland code, we can do that; the hue parameter of the relevant color functions would have to take some appropriate keyword to indicate it's hue-less, and we'd reflect that in OM and TypedOM as well.

But this isn't directly relevant to the issue at hand. Right now, this "missing hue" state is not directly reflected in the serialization or specifiable by a user (we can't write hsl(calc(NaN * 1deg), 50%, 50%), for instance). It currently exists solely as a specification device, and as such we can talk about however we'd like; the point of me raising this issue is to suggest we talk about it as a "missing hue" rather than as an IEEE-float concept that can't actually be used for that argument anyway.

It should be noted that there is a lot of prior art in Color libraries for using NaN for achromatic interpolation.

Sure, a lot of programming languages (JS and C++, in particular) just use a double to represent the hue for hue-ful colorspaces, and as such, using NaN as a sentinel value isn't unreasonable. By doing so, they're not stating that a NaN is semantically a missing hue, they're just saying that NaN is outside the value range of a meaningful hue, and so it's safe to use it to communicate the "missing/present" bit, without having to complicate the user interface for the color code by carting around an extra boolean.

However, that's ultimately a hack due to the fact that these langs have weak/non-ergonomic type systems, and so smuggling in extra data via sentinel values is a reasonable compromise of usability vs semantics/type safety. In languages that have a better type system, like Rust, the standard practice is to actually specify the secondary values, like with an Option(double) or something to indicate that the angle might be missing; this lets NaN retain its normal meaning of "you done goofed", so the class can throw an error when it shows up. CSS similarly can ergonomically accept <angle> | missing to express the desired semantic in a straightforward and readable way.

That ...seems like hugely problematic behavior that we should, at the very least, get group consensus on before we accept it as something to design other specs around.

This has been the specified behavior of NaNs since 2014, and was discussed in https://lists.w3.org/Archives/Public/www-style/2014Apr/0101.html. Note the convo there reflects what I said above, too - NaN is produced solely as a result of an authoring mistake, so it doesn't matter what it turns into, but ideally it turns into something that makes the mistake likely to be noticed. Given the several subsequent discussions we've had over this chapter in CSSWG calls/meetings over the years, I think it's safe to say the group treats it as uncontroversial.

If you'd like to revisit it, okay, but I think you'd need to give a pretty good reason why we actually want hsl(calc(0deg/0), 50%, 50%) (or the other forms that resolve to NaN) to be a valid way to produce an achromatic color, versus writing it out explicitly as hsl(missing, 50%, 50%) or something. I think that would be a pretty hard sell, but I won't stop you from trying. ^_^

[tabatkins]

A quick search for NaN in V&U4 issues didn't turn up any motivation for this strange censoring.

Oh yeah, as suggested by the mailing list link in the preceding comment, that's because the specification for this predates our use of GitHub Issues by a year or two. ^_^ Check that message thread for the reasoning.

[svgeesus]

since you only produce NaN via writing erroneous code

No, that is incorrect.

the actual behavior doesn't much matter anyway;

It really does matter, as the cases cited demonstrate.

Right now, this "missing hue" situation is solely caused by interpolation

No, it is cased by colorspace conversion regardless of whether you plan to interpolate it

in a hue-ful space,

The correct term here is cylindrical polar color representation btw

when an achromatic color is originally defined in a hue-less space.

Right, when an achromatic color is converted to a CPCR

It never shows up in a way that actually gets exposed to users,

It sure does

since the intermediate interpolation has a well-defined hue at all times.

Happens outside of interpolation.

[svgeesus]

If you want this state to be explicitly specifiable by userland code, we can do that; the hue parameter of the relevant color functions would have to take some appropriate keyword to indicate it's hue-less, and we'd reflect that in OM and TypedOM as well.

Yeah, we are going to need that. Well, we (and several color libraries) have that already, but if we conclude that censoring NaN is desirable then yeah, we will need some other value.

[svgeesus]

NaN is produced solely as a result of an authoring mistake, so it doesn't matter what it turns into,

If that is your axiom then, since it is untrue, we need to revisit this decision.

Sure, NaN can be produced by authoring error. But that is not the only way it can.

[tabatkins]

"NaN used as flag for smuggling an extra boolean into an attribute defined as a double" is different than "NaN produced as result of erroneous math". Like I said, languages with weaker or less ergonomic type systems do the former to avoid having to burden their APIs with carrying around an extra boolean, and are okay with accepting that it unfortunately conflates with the latter case (and thus some erroneous code is instead interpreted as correct code that does something different). CSS does not need to do that.

Are you really wanting to argue that hsl(calc(0deg/0), ...) should be treated as an achromatic color? Like, that's intentionally something you desire for this function? Because I think you'll have a really hard time selling that to the WG, when CSS already has a way of indicating non-double values (namely, a keyword). CSS has many examples of a value that is either numeric or a single keyword like none or normal; in exactly none of these do we smuggle the non-numeric value in via a numeric sentinel value, and I don't see why this case justifies doing so.

No, it is caused by colorspace conversion regardless of whether you plan to interpolate it

Sure, but all such conversions are censored away into a color with a hue before authors see it, right? That's the point I'm making there - this is a spec-internal concept that is only exposed to authors by way of the effect it has on other processes; it never shows up in a serialization, and authors can't write it directly on their own.

(Tho fwiw, as far as I can tell your general statement is not true; colorspace conversions don't produce NaN. The only example in the spec that describes converting from a hue-less to hue-ful representation is converting Lab to LCH, where H is calculated as atan2(b,a). If the Lab color is achromatic (a and b both 0), atan2(0,0) returns 0. The HSL section doesn't list an RGB->HSL conversion; the HWB section does, but it references an rgbToHsl() function that doesn't exist in the document or any of the supporting .js files, so I can't tell how it would calculate the hue of an achromatic RGB color. However, I think the common practice is to explicitly check for the max and min RGB channels being equal, and returning 0 for that case. The only mentions of a NaN hue are in 4.2, defining <hue, and the interpolation section.)

[LeaVerou]

After Tab's replies, I can now see both sides of this, so I'm going to mostly step back and observe the rest of the discussion.

I still think that handling NaN as Infinity is completely inconsistent with any other language that uses NaN, as well as with IEEE 754, but if we don't use it here, perhaps the effects of that will be more limited.

But if we do what Tab is proposing, how would this "missing" value serialize in Typed OM and the like? It would need to be yet another object, which complicates the object model even more. And eventually we are going to have a Color object for the Web Platform, separate from Typed OM. How is it going to be represented there?

[svgeesus]

Are you really wanting to argue that hsl(calc(0deg/0), ...) should be treated as an achromatic color? Like, that's intentionally something you desire for this function?

No. That is your model of "the only way NaN can occur", not mine. Mine is

let gray = new Color("Lab" [50, 0.00001, 0.00002]);
let angle = gray.to("LCH").hue;

CSS already has a way of indicating non-double values (namely, a keyword).

As I already said:

Obviously it can be represented textually in CSS syntax, or in the (string-based) CSS OM

and as I (meant to) continue

but how can it be represented in Typed OM or a Color API or when being passed back and forth between CSS and JS?

On the observability of the value

No, it is caused by colorspace conversion regardless of whether you plan to interpolate it

Sure, but all such conversions are censored away into a color with a hue before authors see it, right?

You keep stating this. No. Why would it? The spec is already very clear that some cylindrical polar color representations have an undefined hue. You seem to believe that it is censored away into +infinity which then becomes, I dunno, 360?

[svgeesus]

The non-normative, deliberately simplified, sample code can omit this subtlety but you are right, the "Converting" sections should state this clearly.

So looking at real code:

		lab (Lab) {
			// Convert to polar form
			let [L, a, b] = Lab;
			let hue;
			const ε = 0.02;

			if (Math.abs(a) < ε && Math.abs(b) < ε) {
				hue = NaN;
			}
			else {
				hue = Math.atan2(b, a) * 180 / Math.PI;
			}

			return [
				L, // L is still L
				Math.sqrt(a ** 2 + b ** 2), // Chroma
				angles.constrain(hue) // Hue, in degrees [0 to 360)
			];
		}

[svgeesus]

Example of d3.js deliberately choosing NaN to represent achromatic hues, and also black and white chroma

[svgeesus]

Null handling in Coloraide