html怎么去除小数点,css中小数点的精度问题

今天同事遇到一个奇葩的问题，我以前好像也遇到过，但没有深究，这告诉我们，遇到问题一定要刨根问底，否则将来某一天你一定还会与它不期而遇😂

我们经常会遇到一些横向排列的布局，并且横向排列的总宽度要大于显示宽度，如轮播图，左右滑动菜单等。通常的做法就那么几种：

white-space:nowrap + display:inline-block

display:box/flex + box-flex/flex:1(or other)

float + 父元素宽度动态计算

步入移动互联网时代后，大多使用第二种了，而我却比较喜欢第一种，虽然需要加点小hack去除间隙。我同事正好使用了第三种，于是遇到了这个奇葩的bug

问题是这样的，一个左右滑动菜单，共有四个栏目(有几个栏目是从后台获取的)，分别获取了这几个栏目的宽度，然后设置其父容器的宽度为这几个栏目宽度的总和。逻辑上没有任何问题，然而栏目却只出现了三个，设想可能是宽度不够，将父容器宽度+1，第四个栏目果然出来了。

明明计算好的，为什么会这样呢？用getComputedStyle分别获取了四个栏目的宽度，发现居然有个66.3px，然而用Zepto获取其宽度，赫然是66px。。。那么问题就找到了，父容器的宽度小了0.3px，当然装不下这四个栏目

为什么会小0.3px呢？难道Zepto做了什么处理吗？翻阅其源码后发现：

尼玛啊，Zepto你要不要如此坑爹。。。

故事到这里就结束了吗？然而才刚刚开始。。。

尝试将上面提到的父元素的宽度设置为修正后的宽度，发现然而并没有卵用。。。

看下图：

简直毁三观啊。。。估计这时候浏览器会说：臣妾做不到啊。。。

这也难怪Zepto会把小数点给四舍五入掉，它的存在根本没有太大的意义啊

再看一张毁三观的图：

分三种方法查看该元素的宽度，居然得到三种不同的答案，浏览器你的节操呢😂

但是从这里可以看出来，以后再获取宽度的时候，使用offsetWidth将是比较保险的选择，当存在小数点的时候，它一般要比实际显示的宽度要略大一些。

另外经过测试还发现，当小数点的值是.25/.5/.75的时候，通过getComputedStyle取得的值是精确的，并且审查元素的时候，看到的宽度也是相同的。(但也存在特殊情况，如inline-block元素里面的文本内容超过该元素的宽度的时候，将会发生更不可思议的情况，通过style设置的宽度，用getComputedStyle获取的宽度是这个值，但直接审查元素或通过offsetWidth获取的宽度却不是该值)

通过本文我们可以看到，将Zepto的宽/高度向上取整，应该可以解决上文提到的同事遇到的bug。

Tips: $0指代当前正在审查的元素。