Gray color is not correctly cast to a string

Question

Gray color is not correctly cast to a string

Closed this issue 6 months ago · 7 comments

I noticed a problem when trying to use the API in the developer tools.
Specifically, when I tried to convert the color 'gray' to HSL and then to a string, the result displayed 'none'. Other color names do not have this result.

(new Color("gray")).to("hsl").toString()
>> 'hsl(none 0% 50.196%)'

Answer 1 · 2024-03-09T18:53:59.000Z

What hue would you suggest gray has? The reason why you get an undefined hue (none) is because the color is achromatic and has no hue.

Answer 2 · 2024-03-10T05:29:20.000Z

I suggest use 0 instead none when color stringify. So, I expect hsl(0 0% 50.196%) but not a hsl(none 0% 50.196%)

Because converting color with none to other format is another issue:

(new Color("hsl(none 0% 50.196%)")).to("srgb").toString()
>>> 'rgb(none none none)'

but with 0 instead none it works corretly:

(new Color("hsl(0 0% 50.196%)")).to("srgb").toString()
>>> 'rgb(50.196% 50.196% 50.196%)'

Answer 3 · 2024-03-10T05:49:40.000Z

none is now supported in the CSS spec and has been implemented in a number of browsers. Gray doesn't actually have a red (0deg) hue, but regardless of technicalities of what is more correct, I can imagine some people desiring a way to serialize without none. There was an option to do so for some amount of time, but it was removed in e28cd6a.

Below does look like a bug to me though. Undefined values should be handled before conversion, but that does not appear to be happening currently.

new Color("hsl(none 0% 50.196%)").to("srgb").toString()
>>> 'rgb(none none none)'

Answer 4 · 2024-03-10T05:56:53.000Z

I just fixed problem for a while with a .toString().replaceAll("none", "0") after any stringify.

Answer 5 · 2024-03-10T06:00:34.000Z

I personally think an option to allow omitting none in serialization seems reasonable, but thenone conversion issue should definitely get fixed.

Answer 6 · 2024-03-10T14:43:38.000Z

I've created a PR (#476) to adjust the bad "none" handling across the library.

@svgeesus and @LeaVerou would need to make a decision on whether it is desired to expose conditional "none" serialization. If they decided that they wanted to move forward with this, I'd be happy to make the PR.

Answer 7 · 2024-03-14T13:38:51.000Z

None bug has been fixed on main. A new issue is opened that, when implemented, could solve the serialization request: #479. I will resolve this as a duplicate of that issue. I advise following that issue to stay on top of progress.