Lighten will remove the hue and saturation when reaches 100%.

[hackhat]

var a = tinycolor('hsl(11, 100%, 96%)')
console.log(a.toString()); // "hsl(11, 100%, 96%)"
a.lighten(10);
console.log(a.toString()); // "hsl(0, 0%, 100%)"

I would expect to be

console.log(a.toString()); // "hsl(11, 100%, 100%)"

In your docs you say "Providing 100 will always return white." but I think is a good idea to keep the data anyway, in this case I need to darken and instead of being red again, is grey.

IMO a.lighten(10) and then a.darken(10) should reverse to the initial color.

[bgrins]

I see the point. This is tricky because the color is stored in RGB internally. So since hsl(11, 100%, 100%) converts to rgb(255,255,255) once the call to toString() happens later the data has been lost.

I can't think of an easy way to work around this off the top of my head. I'd like to avoid storing _h, _s, _l for every color, since we would potentially want to do the same thing for every color format.

[hackhat]

I see the problem...and is not that easy to solve..

I think the only way is to keep hsl internally instead of RGB.

since we would potentially want to do the same thing for every color format.

I don't understand why this is bad

[ephemere000]

I agree with hackhat. The internal format should keep the original values passed. RGB internal representation is the worst as it does not contain any info: hue, luminescence, lightness, saturation... Everything must be converted to these systems through mapping functions.

I was animating colors and as soon as I would reach a saturation or lightness of 0 (in HSL), everything would go red (hue 0). In these cases, the RGB values are all equal, eg. rgb(64,64,64). No formula can extract back any of the original hue. Arbitrarily, tinycolor resets them to default values: 0 for hue (red).

RGB is a thing from the 90s to represent colors. It can be useful in some cases for some type of applications, but we now use other color systems to represent human perception (not LCD/CRT physical intensities). Modern applications require: luminescence, brightness, contrast, triad, complementary, themes...

RGB can't keep any original info, they don't exist in its system. I agree with hackhat, the internal representation should keep all the parameters of all the original formats that were passed. These are minuscule structures compared to other JS objects. It would still be tiny.

I realized that tinycolor is basically just a structure storing RGB values with conversion formulas. I will be looking for other tools that are more sophisticated and that represent the actual color theories.