position:sticky的兼容性嘗試

開篇

筆者剛剛結束淘寶的工做，如今加入了一家有青春活力的垂直電商公司，正對着阿里巴巴的西溪園區，最近一直在熟悉新的工做環境和規範，所以博客有好些時間沒有更新了，在此抱歉！
在忙碌完公司的發佈系統以後，逐漸接觸到具體的業務。在這裏主要介紹下關於css3草案的position：sticky屬性的兼容。

問題

目前前端的h5有個需求，就是「當頁面上的若干個標題被拖動到視口的頂部時，則顯示一個被定位到視口的頂部的tab標籤，可對這個tab標籤進行點擊導航，並在某個特殊的狀況下隱藏」。最簡單粗暴的作法就是針對document.body作scroll偵聽，在函數中遍歷全部的標題並計算出getBoundingClientRect計算出距離適口的頂部距離，決定是否顯示tab欄或者活動標籤，可是在這裏可能會出現一些性能問題：
+ 在瀏覽器端和安卓設備上，scroll事件連續觸發，若是在偵聽函數中作過於複雜的判斷，確定會暫時阻塞ui（主）線程的渲染，形成卡頓
+ 每次在偵聽函數中都執行一次getBoundingClientRect函數，都會致使ui線程刷新渲染隊列，進行一次layout和repaint，有可能形成卡頓
+ 在ios設備中，scroll事件在上下滑動的過程當中js不會連續執行，只在滑動結束的時刻執行一次，而且不支持左右滑動事件的觸發

針對上述問題進行修復，其實並不困難：
+ 針對scroll作throttle節流，避免每次滑動都執行，能夠設置時間間隔，如50ms
+ 在偵聽函數中計算元素的layout屬性，可用setTimeout在定時器隊列尾插入任務，異步渲染
+ ios設備實現了一個屬性－position：sticky，能夠不用js來完成粘性佈局

深刻

針對sticky佈局的兼容性，咱們很容易兼容大多數移動端瀏覽器。在pc和安卓的chrome中並未實現該屬性，而在pc和iOS 的safari中所有兼容該屬性，所以針對iOS能夠單獨使用sticky完成兼容。
sticky佈局有着幾個條件：
+ 元素並不會脫離文檔流，當元素被粘在視口的頂部時，原來在文檔流中的位置仍然佔據，這點相似relative定位
+ 元素相對於其最近可滾動的祖先元素「粘性定位」，若是其祖先元素都不能滾動，則相對於適口定位
+ 元素最近的祖先元素overflow設置爲非默認值visible時，則元素相對於該祖先元素進行sticky定位。若最近的祖先元素設置爲overflow:hidden，則元素不會sticky定位
所以解決ios的代碼能夠這樣：

// sticky類爲粘性佈局的樣式設置
if (gtIOS6) {
    // 大於等於iOS6版本使用sticky
    $tab.addClass('sticky');
}

.sticky {
  position: -webkit-sticky;
  position: sticky;
  top: 0;
}