瀏覽器對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，進而四捨五入以後寬度大於實際渲染寬度