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

I think I'm more or less convinced to represent this with a keyword (I'd suggest `none`, `missing` sounds like an error).

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

Pretty sure @svgeesus was not suggesting that authors define an achromatic color via `hsl(calc(0deg/0) ...`, I think he was expecting `NaN` to become part of the language that can be specified, so that authors would write `hsl(NaN ...`. 

I do agree however that it would be good to distinguish intentional undefined hues from error conditions

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

This discussion made me wonder why none of the JS libraries use `undefined` or `null` to represent undefined hues, and use `NaN` instead. 🤔 



-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6107#issuecomment-810678816 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 01:09:08 UTC