You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This option allows users to limit the default precision to what's defined in precision, but doesn't round the number if the rounded number isn't equal to the number itself. This may sound a bit vague, so let's demonstrate this with an example:
Let's assume you have configured precision: 5 and allowRounding: false:
calc(100% / 3) will output calc(100% / 3) because calc(100% / 3) != 33.33333%
calc(100% / 4) will output 25% because calc(100% / 4) == 25%
What's the advantage? We never have rounded numbers which can cause issues like twbs/bootstrap#27374 and we don't have expressions like calc(100% / 4) that can be simplified.
#61 was about adding an option which can be disabled to keep calc when the rounded version is not the same as the original value. So by default it would have been the same.
@MartijnCuppens 👍 Can you send a PR again? For next major version we set allowRounding: false by default because we potentially can break code, it is bad.
@evilebottnawi, the true behaviour is the same as it is now (I described this in the PR description #61 (comment)). I could also call it disallowRounding and set it to false if that's clearer.
precision: 'safe' would still need some kind of precision. Lets say for some reason the generated value would be: 15.35153465435186437435513 (and this is the exact number, no numbers after the last 3). That's a pretty long number, probably something you don't want. This is why I split precision & allowRounding.
Activity
alexander-akait commentedon Mar 27, 2019
/cc @MartijnCuppens problem still exists, can you provide codepen where
33.33333%!==calc(100% / 3), because browsers already do sameMartijnCuppens commentedon Mar 27, 2019
I guess this is what you are looking for: https://codepen.io/MartijnCuppens/pen/rREmxN?editors=1010 (For some resolutions the buttons do have the same width, but in many cases they don't)
alexander-akait commentedon Mar 27, 2019
hm looks like we potentially can break code
alexander-akait commentedon Mar 27, 2019
I think we need new option for this, also i think we should don't round
calc(100% / 3)by default (it is unsafe).MartijnCuppens commentedon Mar 27, 2019
#61 was about adding an option which can be disabled to keep calc when the rounded version is not the same as the original value. So by default it would have been the same.
alexander-akait commentedon Mar 27, 2019
@MartijnCuppens 👍 Can you send a PR again? For next major version we set
allowRounding: falseby default because we potentially can break code, it is bad.XhmikosR commentedon Mar 27, 2019
@evilebottnawi You can reopen the PR.
alexander-akait commentedon Mar 27, 2019
@XhmikosR still need rebase
XhmikosR commentedon Mar 27, 2019
That is something @MartijnCuppens can do after you reopen it.
MartijnCuppens commentedon Mar 27, 2019
It's now rebased
alexander-akait commentedon Mar 27, 2019
@MartijnCuppens What do you think about disable round by default as i describe above in next major?
MartijnCuppens commentedon Mar 27, 2019
@evilebottnawi, the
truebehaviour is the same as it is now (I described this in the PR description #61 (comment)). I could also call itdisallowRoundingand set it tofalseif that's clearer.alexander-akait commentedon Mar 27, 2019
@MartijnCuppens Maybe we can do better:
?
MartijnCuppens commentedon Mar 28, 2019
precision: 'safe'would still need some kind of precision. Lets say for some reason the generated value would be:15.35153465435186437435513(and this is the exact number, no numbers after the last 3). That's a pretty long number, probably something you don't want. This is why I splitprecision&allowRounding.fix: do not replace fractions with imprecise floating point numbers