記一次CSS彈出動畫的Bug

在寫 jquery weui 的乙個picker的彈出動畫的時候，我是通過css動畫實現的。

css**如下：

.weui-picker-modal 
}

js**如下：

$.openpicker = function(tpl)

其實原理很簡單，就是建立dom的時候，通過 translate 把彈窗y軸向下平移 100%，於是就看不到了，然後顯示的時候再設定 y 軸平移為0，就可以看到乙個css動畫的彈出效果。

按道理講是應該有動畫的，因為我是先建立了dom，並插入到頁面，然後才新增了weui-picker-modal-visible類做動畫。但是事實卻是ios上第一次沒有彈出動畫，那麼也就意味著其實在ios上，建立dom和新增weui-picker-modal-visible其實是合併成了一步，才會出現開啟的時候沒有彈出動畫。

注意這一行奇怪的**dialog.show()，其實這一行**就是想確保在新增類之前讓dom已經建立完畢。然後突然想到之前我有研究過js效能優化相關的內容，其中有一條大意就是「如果連續對dom進行多次操作，瀏覽器可能會調整這些操作的順序以提公升效能」，其實就是說瀏覽器會把dom的修改操作盡量提前到被插入文件流之前進行，因為插入文件流之前進行修改就不需要進行渲染，所以這裡其實如下三行**在ios中其實被提前到了dom插入操作前：

dialog.show(); //注意這一行奇怪的**

dialog.addclass("weui-picker-modal-visible");

本來是先把dom插入文件流，然後進行dom操作，優化後大致相當於變成了這樣：

var dialog = $(tpl);
dialog.show(); //注意這一行奇怪的**
dialog.addclass("weui-picker-modal-visible");

那麼很明顯，這樣做是無法出現動畫的。而如何避免出現這種情況呢，之前的部落格也提到了，就是在插入文件流之後，執行一次讀取css屬性操作，於是瀏覽器不得不立刻執行插入操作才能計算出css的屬性值：

$.openpicker = function(tpl)

只需要改動一行**即可解決這個bug。之前認為進行一次show操作就可以保證已經實際插入文件流了，這種想法是錯的，只有進行一次css屬性的讀取才能百分百保證。

可能有人要問為什麼只有ios上有這個問題，那估計是因為ios更加重視這種ui上的效能優化，所以盡量進行dom操作的合併。

所以如果大家以後自己寫css動畫，建立乙個dom之後立刻加乙個類進行動畫，也有可能會碰到這種bug，那麼只需要在新增動畫類之前隨意讀取乙個css屬性即可。

記一次CSS彈出動畫的Bug

記一次前端bug排查

記一次sum SQL 統計BUG

記一次npm的奇怪bug

記一次CSS彈出動畫的Bug

記一次前端bug排查

記一次sum SQL 統計BUG

記一次npm的奇怪bug

相關推薦