Add possibility to disable rounding

[Stéphane Goetz]

Hi,

I'm no expert in color spaces so what I say might have some knowledge gaps.

Would it be possible to add an option to disable rounding when exporting values ?

I'm working on a postcss plugin similar to postcss-color-mod-function and I have to perform multiple color space conversions that make it lose precision on each conversion.

For example
Starting with an RGB color, converting to HWB to increase blackness, then back to a colord object.

I might misunderstand a few features or not get that they exist but I feel that by doing so I'm losing information in between calculations.

As an example : toHwb() could have an optional toHwb(rounded?: boolean = true) argument

I'm ready to contribute that Pull Request if that's something you're interested in.

[Vlad Shilov]

Hi! Could you please provide some examples of the color modifications you performed?

[Stéphane Goetz]

Sure,I have one example that is a bit more complex than the probable real use case but here goes :
color-mod(var(--color) blue(10%) hue(+ 10deg) rgb(+ 0 10 0) tint(10%) whiteness(+ 10%) saturation(+ 10%) blend(rebeccapurple 50%));

So we start with an RGB color, then

1. add 10% of blue, needs to convert .toRgb() change the value and create a new object
2. add 10deg of hue using colord's hue(value)
3. add 10 of green, needs to convert .toRgb() change the value and create a new object
4. tint() would mix 10% of white in the color, using colord'smix(value, percentage)
5. whiteness would need to convert to HWB, change the Whiteness value, then create a new object
6. saturation would use colord's saturate(value)
7. blend would use colord's mix(value, percentage)

So granted most of the features I need are here and that's awesome, but for example the method to add more blue and more green would require to do toRgb() and to add whiteness it would need toHwb()

But as said that's an extreme case on purpose, I guess most cases will be more like color-mod(blue whiteness(+10) blend(orange 20%)) but that still needs a conversion

[Vlad Shilov]

Hi! Sorry for the delay (the renovation is killing my schedule).

I think I can try adding options: { round: true/false } argument to all toRgb, toHsl, toHvs and other methods to make it possible to use libraries inside of other libraries like yours.

Hope it won't affect the library size much.

[Stéphane Goetz]

Hi, no worries, we all have a life outside of open source :D

I have seen that other libraries have a "precision" argument where they can just give a number and the rounding is done using that.
For now I don't need that feature anymore but I think it could still be a useful feature in the future for others

[Nantris]

This would be a great addition. We have a color array that has alpha values in 1/16th intervals like:

• 0.9375
• 0.6875
• 0.5625

It's difficult for a new developer to intuitively realize that they're looking at 1/16th intervals because after switching to colord the values look like:

• 0.938
• 0.688
• 0.563

[Brian Bugh]

Rather than "rounding" being a boolean, it would be preferable if it was to a specific precision, with a default of 0

toHslString({ precision: 2 })

because for example in the browser, Firefox will convert #0008 to hsla(0, 0%, 0%, 0.53), but the actual alpha value is 0.5333333333333333. In order to reproduce browser-like behavior, we need precision 2.

and extra credit to strip insignificant zeroes by default but provide an option:

toHslString({ precision: 2, keepInsignificantZeroes: true })