[Feature Request] Adopt HCL Color Space For Color Modules

[MrLoh]

Hi, first of all. I'm a huge fan of this project. This is related to https://github.com/styled-components/polished/issues/148

But you might want to go even further and just adopt HCL color space as a replacement for HSL, which has similar problems because it has nothing to do with our perception of colors which ultimately matters for our UI designs.

I think this article gives a great overview of the issue. With HCL you can simply adjust the luminance value to achieve a perceptually darker color. I think chroma.js has an implementation of HCL, maybe that is a good starting point.

I'd be happy to help out with this. I'm not an expert either though.

[bhough]

@MrLoh We'd definitely be interested in adding HCL color space and are open to PRs/Discussion on the best way to do so.

[MrLoh]

@bhough you don't want to add any external dependencies, right? Because otherwise chroma.js seems to be a really small and powerful library for advanced color manipulation in more professional color spaces like HCL. It would of course be possible to just copy some of the code from chroma, but that's generally not such a good practice I'd say.

[bhough]

@MrLoh we definitely don't want to add any external dependencies. Also our color methods work differently than chroma.js as ours are more functional (composable) where theirs take a more object oriented approach. So why you can certainly look to their approach to inspiration, we'd need to implement it differently based on the need for them to be composable.

[MrLoh]

Hey @bhough of course chroma uses a more object oriented aproach, but I think it could as easily be wrapped in a more functional API.

What exactly do you mean by composable, I mean I get the FP term, but I haven't seen function composition in polished, so what exactly is your API design philosophy.

A more object oriented approach like the one from chroma of course also has some big benefits especially for composability, because it can represent a color as the object it is without the need to serialize and deserialize it at every alteration. Like when you do. chroma('green').darken(0.1).saturate(0.5).hex() instead of chroma(chroma('green').darken(0.1).hex()).saturate(0.5).hex() which is basically what the purely typeless functional code does that always serializes to a hex value. Of course it is hard to imagine how such an object oriented approach would fit into polished, totally agree. I'm just trying to understand what exactly your architectural requirements for polished are.

[bhough]

@MrLoh All our color methods are composable like this:

const pastelize = compose(
  tint(0.3)
  lighten(0.3)
  saturate(0.2)
)

pastelize('#F00')

One of the main reasons we don't go object-oriented like chroma is that it requires that items like colors in themes have to then be instantiated as chroma color objects before they can be manipulated. Which means either converting an entire theme over, or doing it one off whenever you need to manipulate a color.

Another reason we like composability is that it allows you to be able to create your own custom color functions based on polished helpers. @nikgraf talks more about that here: https://www.youtube.com/watch?v=qJgff2spvzM

[quantizor]

I'd like to make an alternate proposal for using HSLuv color space under the hood: http://www.boronine.com/2012/03/26/Color-Spaces-for-Human-Beings/

Reference implementation: https://github.com/hsluv/hsluv

Essentially, it's a modified version of HSL that avoids unrenderable colors and helps implicitly handle certain color accessibility concerns.