在寫 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屬性即可。
記一次前端bug排查
前言 時隔三年,終於記得要找回賬號密碼開始寫筆記了,這周剛加入了乙個後台管理系統專案,測試反饋系統重新整理時經常會直接登出,嚴詞要求解決這個 重大 bug,so尷尬。更嚴重的是發現系統在ie上直接登不進去,嬸可忍叔不可忍,於是我開啟了苦逼的尋bug之路。既然是登出了,當然會有登出請求,chrome重...
記一次sum SQL 統計BUG
create table asgard share records id bigint 20 not null comment 分享記錄id status tinyint 3 unsigned not null default 1 comment 資料狀態 1 正常 0 刪除 create time...
記一次npm的奇怪bug
近幾天npm不知怎麼了不能安裝包了,連cnpm都不能安裝了,於是開始開 ku 心 bi 的除錯。網上的方法基本上全都試過了,結果出現了這個東西 這是讓我刮獎嗎?google一下,還真有這樣的錯誤,好像是埠被占用了。好嗎,三下五除二改下埠,發現還是不行。仔細觀察發現網上貼出來的錯誤跟我的錯誤還不一樣,...