Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

negative shade percentage converts hex colour to rgba #1810

Closed
zanona opened this issue Jan 16, 2014 · 7 comments
Closed

negative shade percentage converts hex colour to rgba #1810

zanona opened this issue Jan 16, 2014 · 7 comments

Comments

@zanona
Copy link

zanona commented Jan 16, 2014

I have noticed that this is happening:

@color: #269FEB;

body { color: shade(@color, -15%); }

/*Outputs*/
body {
  color: rgba(44, 183, 270, 0.9999999999999999);
}

which is a serious problem if you are dealing with IE8- or any other browser which doesn't support RGBA color specification.

When using an hexadecimal colour style by using the shade method, the same colour style would be expected back. However, this doesn't seem to happen when using positive values for the shade amount and it's also not applied to every negative values, but only some of them (probably floating numbers)

@seven-phases-max
Copy link
Member

This is somewhat related to #1524, #1326 and similar... All this is easy to fix (and AFAIK it is the only proper way to fix) by rounding numeric values to a reasonable number of digits after decimal point on output. We just need to decide what this reasonable number is (2, 3, 4, 5, 6, more?).
E.g. what result it should be for 1.1313131313131313131313:
1.13
1.131
1.1313
1.13131
1.131313
?

(Things like 42.0000000000000001 or 0.99999999999999999999 become proper 42 and 1 with either of these rounding precisions).

@seven-phases-max
Copy link
Member

P.S. And a workaround for this particular case:

body {color: fade(shade(@color, -15%), 100%);} // make sure color is never transparent

@zanona
Copy link
Author

zanona commented Jan 16, 2014

Looks like a good workaround @seven-phases-max, thanks for the tip. ;)

@matthew-dean
Copy link
Member

I think anything more than 3 or 4 decimal places seems overkill. I presume 0.999999~ has to do with the precision (or imprecision) of floats in JavaScript math operations?

@lukeapage
Copy link
Member

On dotless we rounded to 2 then 4, then 6 decimal places as people
complained but that was % not colour opacity.

We should probably round to 8 decimal places everywhere to avoid all
precision errors in JavaScript.

@seven-phases-max
Copy link
Member

We could simply expose this as an option (e.g. --num-precision=8 - maximum number of digits to appear after the decimal point) but I wonder if we want another option since there're too many piling up already :).

@seven-phases-max
Copy link
Member

Fixed with #1814.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants