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

> (We are probably getting lucky and the implementation of atan2() we are using seems to return 0 when both arguments are 0, but the c spec seems to say that it is a domain error, so we should probably add an explicit check).

If both `a` and `b` are zero, you will get zero, but with Lab, often `a` and `b` are not zero when converting from an achromatic sRGB color unless you round them off.

```py3
> new Color("#777").to('lab')
Color$1 {
  _spaceId: 'lab',
  toString: [Function: toString],
  coords: [ 50.03434402595761, -0.0021727557177886325, -0.008043723319994811 ],
  alpha: 1
}
```

If they aren't rounded off, you get some wild values for hue as `a` and `b` get very close to zero. But, if you round them off, conversion back and forth gets more unstable. Though, conversion from Lab to sRGB doesn't seem that stable to begin with as you get really close to zero chroma.

But even if they yielded zero reliably, zero is still a hue (red), but an achromatic color doesn't have a hue, so `0` is not really correct. Gray doesn't have a red hue, and when you mix it with another color (in a cylindrical space), you don't want the red to influence the final mixed color as there was never any red to begin with.

What I think is trying to be done is setting the stage for proper mixing by providing a way to make clear when a hue value is meaningless. How that happens is the argument, I guess.

I'm just interested to see how it all plays out 🙂.


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


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

Received on Wednesday, 24 March 2021 03:12:07 UTC