1、chrome opacity非1時border一、圓角邊框顯示不全問題浮現(xiàn)條件應當都知道，border-radius:50%可以讓元素正方形元素表現(xiàn)為正圓，深化理解其表現(xiàn)機制可參見我之前文章：css3 border-radius知多少？。假如元素設置了border邊框，則會表現(xiàn)為一個正圓圈圈，類似這樣：但有時候，border邊框的這個圈圈會在邊緣處發(fā)生剪裁，不是一個完善的圈圈了，類似下面這樣：圈圈的左側不是圓的了，而是像被什么東西一刀切下去，成了直直的了。假如是在retina屏幕下，則一刀切的效果可能還要越發(fā)顯然，上下左右都有可能發(fā)生剪裁。浮現(xiàn)這種渲染問題，需要滿足下面兩個條件： 元素的透亮度

2、opacity不是1； 元素的位置并不是完善起止于屏幕的像素點上； 第一個條件很好理解；那其次個條件是什么意思呢？對于一般的顯示器，設備像素比devicepixelratio是1，也就是最小顯示單位（渲染單位）是1像素。假如某一個元素的起點是從0.5像素開頭的，那這個元素的開頭位置就不是正巧在屏幕的像素點上，而是中間。這其實是個悖論，既然最小渲染單位是1像素，何來從0.5像素開頭的定位呢？的確，在過去，幾乎全部css屬性設置的小數(shù)值的終于表現(xiàn)都是以整數(shù)像素體現(xiàn)（如margin: .5px = margin: 1px），在老ie時代更堪稱死板（4個25%寬度浮動元素可能最后一個會掉下來）。但是進

3、入css3時代后，狀況就開頭發(fā)生變幻，著重要點名的就是transform變換。因為transform變換基于矩陣計算，無論是旋轉還是拉伸，其點坐標十有八九一定是n位數(shù)的小數(shù)。假如此時我們的掃瞄器根據(jù)最小的1像素開頭渲染，那圖形的邊緣那就是滿滿的鋸齒，渲染效果會十分糟糕（一開頭的transform變換效果然就這么糟糕）。掃瞄器廠商一看，我去，這效果挫到我自己都看不下去，于是下功夫開頭提升渲染體驗。弄了一套算法，對非整數(shù)像素點邊緣舉行柔化，也就是雖然還是占領的1像素的格子，但是邊緣像素點通過半透亮等特別處理，我們視覺上看就好似元素開頭于0.5像素的位置。也正是因為這個緣由，當我們用法對元素舉行非整

4、數(shù)位置的translate位移的時候，元素的邊緣會有一點含糊的感覺。對于imac這種5k顯示屏幕，最小像素點事實上可以小到0.2像素，也就是就是translate移動0.2像素，元素邊緣也不會柔化含糊，但是，移動0.5像素就不一定了。因此，如下的html和css代碼就可以讓圓角邊框不規(guī)整：.ele display: inline-block; width: 40px; height: 40px; border: 1px solid fff; border-radius: 50%; transform: translate(.5px, 0); opacity: 0.6; 按照我的測試，除了chr

5、ome掃瞄器有圓角邊框不規(guī)整的問題外，ie掃瞄器的渲染也同樣有問題，表現(xiàn)為右側邊緣顯然健美：但是，假如opacity設置為1，則無論ie掃瞄器還是chrome掃瞄器，又變成完善的圓圈圈了，如下（截自ie）：firefox則表現(xiàn)符合預期。二、假如解決border-radius border部分顯示問題？知道問題浮現(xiàn)觸發(fā)的條件，那問題解決其實已經(jīng)解決了一半了。2種辦法：1. 元素尺寸和位置都在都是整數(shù)像素然而無數(shù)時候這種辦法并不切實際，尤其對于復雜布局，例如我們用法calc計算對元素寬度定位時候，或者line-height用法不簡單計算的小數(shù)時候，或者基于rem的布局等等，想要強制元素尺寸和位置都是整數(shù)并不太簡單。2. 不用法opacity實現(xiàn)半透亮既然我們的問題浮現(xiàn)與opacity不是1有關，那我們就不用法opacity實現(xiàn)半透亮，采納其他的辦法代替。假如我們想使一個邊框變成半透亮，除了opacity外，我們還可以用法rgba或者hsla色彩。例如，上面是一個例子的css代碼換成：.ele display: inline-block; width: 40px; height: 40px; border: 1px solid hsla(0,0%,100%,.6); border-radius: 50%; transform: trans