Re: [csswg-drafts] [css-color-4] Achromatic colors converted to hue-ish spaces should treat hue as "missing", not NaN (#6107)

> 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. ^_^

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6107#issuecomment-803102327 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 19 March 2021 20:23:58 UTC