decimal precision of 10 leads to issues with firefox

[hirbod]

Hi,

I've spent couple of hours to bugfix an issue with firefox yesterday. The main reason is not CSS itself, but when you try to calculate with those values in JS (Firefox only).

I had a masonry grid, which was working perfectly fine before I've ported from browserify to webpack. (node-sass)

Before, my elements had a width of 33.33333%. So my grid had 3 elements in a row. Was working in every major browser.
After my port to webpack, the output transpiled by dart-sass outputted 33.3333333333%. No issues on Chrome, Safari and Edge, but Firefox. Only 2 elements per row.

Searching all the web and debugging via devtools, I tried to change the precision to 5 until I realized this setting is not available with dart-sass.

While I understand that the high percision is a good thing for line-height issues and other scenarios, it does lead to issues if you calculate with high precision values via JS in Firefox.

I've ended up adding some some ugly margin-right: -0.001px to my elements in order to fix this.
Since I had 0 issues with a precision of 5, I would kindly ask you guys to introduce a precision setting. I don't have any issues with a default value of 10, but you should still give the developer the power to change this value.

[henrycatalinismith]

This is a really fascinating problem and I'm so glad you shared the details here. I'm weirdly excited to try and spin up a demo of this behaviour in Firefox at some point to see it with my own eyes!

Do you reckon you might be able to use something like https://gist.github.com/terkel/4373420 to adjust the precision of those numbers yourself directly? Might be your quickest way to get rid of those margin hacks!

---

Just got a few mins to try and reproduce your issue! You can check out the Codepen where I tried if you like! I wasn't able to reproduce it though.

Chrome	Firefox	Safari

Any idea what I'm missing there? All three browsers are giving me the same result with both 33.33333% and 33.3333333333% widths. I feel like there's something useful to learn about Firefox if I can reproduce this so I'm really interested in seeing it for myself if possible!

I've been thinking more about your use case BTW, and I reckon if you can achieve the precision you need using those rounding functions from that gist above, then you basically already have the power you need to change the precision, and it's probably a better way of solving it than configuring the precision globally. Compare it to any other programming language, like JS for example. If you had a value of 50.93842 in a JS variable but you needed to use it in a context where you only wanted one decimal place (50.9), you'd call toPrecision() on it rather than looking for a global way to decrease the precision of all numbers, right? It's a little less intuitive in Sass because there's no built-in function for that, but I think the same principle probably applies.

---

I also found this issue which seems to indicate that configurable precision is deliberately being phased out across all Sass projects. Looks like there was a lot of trouble with this option in node-sass 5 or 6 years ago because the default precision of 5 was too low for Bootstrap. Increasing it to 10 solved a lot of problems and you still have the flexibility to decrease it on a case-by-case basis using rounding. So I wouldn't hold my breath for this being added if I were you 😇

[nex3]

Although generally speaking we do try to accommodate all the browser issues we can in Sass, in this case you're describing something that's clearly a bug in Firefox—there's no world in which 33.3333333333% * 3 > 100%. Even in floating-point arithmetic (which can get pretty messy), the result is 99.99999999989998%. And given that lower precisions also cause bugs in practice, and configurable precisions have performance and complexity problems, we're not very keen on making the default lower than 10.

[hirbod]

The issue I had was caused by this package: https://github.com/metafizzy/isotope (which does break in Firefox with this high precision values)

Using this values directly via CSS didn't cause any issues, but since the JS does do some math with those values, it got messed up. This might be an implementation issue with the masonry algorithm used by isotope or a JS math bug by Firefox. I am fine with your decision.