浏览器对css小数点的处理
近期在开发的时候遇到一个奇怪的问题，如下图(ios系统，android暂未发现)，第一个和第三个子元素中的角标与父元素始终有一条缝隙，但是第二个没有，因为第一次遇到，没有意识到是小数点的问题，然后从头到尾重新看了相关的样式，布局，设置都没有问题，但是那条缝又明明确确的在那儿
核心代码：
ul {
display: flex;
justify-content: space-between;
padding: 15px;
li {
position: relative;
width: 32%;
...
span {
position: absolute;
right: 0;
top: 0;
...
}
}
}秉着实践出结果，开始调试（iphone6），所有布局相关的样式一个个改值，最后在同事的帮助下，发现把width改为31.5%之后就可以了，此时意识到与css小数点有关系
于是针对这个来分析（下面分析仅仅作为参考，浏览器内核到底怎么工作的，safari和chrome又分别做了什么暂不清楚）：
iphone6宽度为375px，ul宽度为345px，所以32%和31.5分别是110.4和108.675，果然四舍五入之后，前者变小后者变大。网上查找之后说是，浏览器会对css小数点有不同的处理规则，ie向下取整，chrome，safari等四舍五入，参考这两篇文章css布局单元 ，css小数像素问题
大致了解为什么会出现这种情况之后，针对自己这个问题，从深层次的角度分析一下原因，见上述参考链接，webkit内核在渲染元素时，真实渲染区域是固定不变的，但是在文档流中的空间大小是计算出来的，所以直接影响到了下一个元素，出现了第二个元素与第一个元素表现形式不同的情况。如下图是webkit计算方式：
按照上面计算方式计算宽度为32%时，三个元素的结果如下：
- 第一个li，x = 15，width = round(15+110.4) - round(15) = 110
- 第二个li，x = 125.4，width = round(125.4+110.4) - round(125.4) = 111
- 第三个li，x = 235.8，width = round(235.8+110.4) - round(235.8) = 110
我们可以发现，第一个li，实际渲染区域宽度为110.4，但是文档流中宽度为110，所以子元素可活动区域为110，那0.4便是那条空隙
第二个li，实际渲染区域也是110.4，但是文档流中宽度为111，同理第三个计算为110，这便也解释了为什么一三表现形式一样
同理，宽度为31.5时，width分别为：109，109，109，实际渲染宽度为108.675
经过测试验证，ios系统内，safari和应用内webview效果与分析一致，但是通过dom获取元素width时，与上面计算结果不一致，全部都是四舍五入之后的结果，这一点没有搞清楚。但是通过分析验证了问题所在，之后遇到这种情况的时候便有了解决办法：
- 合理设置百分比，使其计算结果小数点>=5，进而四舍五入之后宽度大于实际渲染宽度