Fix lightness manipulators lighten and darken.

[ivansky]

Lightness functions should work in percent. #91

[Qix-]

// @mattbasta @sindresorhus @MoOx can you confirm this is what is expected? This is a breaking change :P

[MoOx]

Per examples here https://github.com/Qix-/color#manipulation many functions seems to be modifiers, so act on the current existing value (so current - current * value) make sense.
If you want to change this behavior for one method, you should do it for all method.
Otherwise, like CSS color functions, you can accept +10% (modify current state, like it's currently) or 10% (brutal change as this PR).

Note: maybe I am wrong, I am not especially a pro about color manipulation :)

[mattbasta]

Both are correct, because each is a different blending function. Each has a valid use case. The question is which is most expected. To me, the existing behavior makes the most sense.

[ivansky]

Many developers will be confused
These blending functions work in other libraries as I proposed.
So, I suggest leave existing functions as is with other names and apply my changes in new major version.
I don't know how to name the current functions. They should not be named as lighten or darken.

[MoOx]

By other libraries you mean Sass and LESS?
Because I didn't see a lot of complain about that overthere :)

[ivansky]

For example

• SASS
• LESS
• Stylus lighten function (has two options, in percent and absolute)
• mexitek/phpColors lighten implementation
• onecolor works as others (example)
• lighten and darken should be absolute lighten and darken should be absolute #53
• Green lighten to 1 is green Green lighten to 1 is green #45
• Lightness manipulation methods fail Lightness manipulation methods fail on color('black'), except negate() #82

Current library has 48 issues. So I guess, issues will be appear again until we resolve it.

[MoOx]

Just one thing imo: you cannot just remove/replace a function. This module has been downloaded so many times...
So I would go for breaking change but keep the old method (for the naming, I don't care :)).
Maybe we can add a parameter to switch between absolute or relative?
In any case, should be adjusted to all similar methods.

[ivansky]

I agree with you. We need to support users. I think, we have 3 options:

1. Leave the old names and add a boolean parameter as third argument of function.
2. Add this breaking change to new major version.
3. Add new functions and do not support the same naming

I like second option as you can see :)

[MoOx]

Adding a breaking change is fine, but you should still offer the relative implementation (eg: relativeLighten or something).

[ivansky]

So, I think name relative implementation as lighter and darker.
Or brighten and what? I don't know a good antonym.
I am not sure, because names should look conspicuous.
Is it fine or not? Please, could you help me with naming.
Unfortunately, I haven't enough knowledge in english.

[Qix-]

This won't make it into the v1.x makeover, but I'd like to look into this more. I agree that those functions are super confusing.

I'll dig a bit deeper, see the differences with them applied to a few images, and maybe suggest a few names and whatnot.

[lvl99]

I'd love to set an absolute value for the saturationl of the color. Maybe a generic term like brightness could be the handle for the absolute, and lighten and darken can remain relative.

[sammi]

I think we keep the existing name: darken, lighten, saturation, desaturation, do abolute percentage changes makes sense. We may need regard the relative changes as a bug, not a feature. So it would not be a concern for break back compatible ablity.

[Qix-]

I'm closing this, upon further review this is not the way this should work (it's a breaking change). Please see #53, as that should be the definitive place for discussion.