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;
}