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

> I don't make the same assumption about you, when we disagree.

I'd love to be wrong, but my initial post was explicitly about the subject of a missing/undefined hue angle when converting between spaces, so repeatedly explaining to me that hues can be undefined when one converts between spaces, and implying that my lack of understanding that fact is a salient point against me in the discussion, has been *immensely* frustrating. (You've done this [here](https://github.com/w3c/csswg-drafts/issues/6107#issuecomment-805416589) and [here](https://github.com/w3c/csswg-drafts/issues/6107#issuecomment-803231246), and in the very comment I'm responding to here, fwiw.)

> No. I have repeatedly taken every reference you make to an explicitly-produced NaN as solely arising from an error, and pointed out that I'm also talking about grays, which are not errors.

NaNs *do not* arise from a color conversion. *Undefined hues* do. Whether we *represent* an undefined hue as a NaN or as something else is the precise question I opened this issue to discuss, and the answer is 100% under our control. (NaNs don't even naturally arise from the most straightforward underlying math, as I pointed out is demonstrated by the sample color conversion code in the spec; you have to *explicitly* detect the undefined-hue case and return a NaN to get it to show up.)

I've also *repeatedly* asked about explicitly-produced (that is, error) NaNs specifically so we can establish whether such NaNs *should* be merged with the "undefined hue" case. Quoting from earlier:

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

I did not say "that is the only way NaN can occur" or anything of the sort, I asked a specific question for a specific reason, and it still hasn't been answered. :/  Do you actively, affirmatively want an explicitly-produced NaN to be the way authors indicate that a color is achromatic? And any accidentally-produced NaNs (that is, erroneous calculations) to be, not an error case, but a valid and correct value that has a well-defined meaning?

Or would you rather authors write `hsl(missing, ...)` or something similar (and implementations to serialize it that way when such a color gets exposed via the OM) to indicate an achromatic color?

I know I *definitely* prefer the latter, and I think you'll have a pretty hard time trying to sell the former to the rest of the WG, considering that this would be an entirely novel way to indicate a non-numeric value across all of CSS so far. We have *lots* of examples of properties that take a numeric value *or* a non-numeric value, and every single one of them so far indicates the non-numeric value with a keyword or similar; not a single one implements this semantic by designating one of the numeric values as a sentinel value for the non-numeric behavior. 

As I've explained in previous posts in this thread, that is something that *Javascript* does (and closely-related languages, like C++ or Java) because they have relatively weak type systems and can't easily and conveniently express that a value should be a double *or* a keyword. CSS doesn't have that problem, nor do other languages with convenient enums like Rust, and so they (and we) shouldn't reproduce the weaknesses of other languages in our language.

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


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

Received on Wednesday, 31 March 2021 00:19:02 UTC