在触屏设备上，一些比较基础的手势都需要通过对 touch 事件进行二次封装才能实现。
zepto 是移动端上使用率比较高的一个类库，但是其 touch 模块模拟出来的一些事件存在一些兼容性问题，如 tap 事件在某些安卓设备上存在事件穿透的 bug，其他类型的事件也或多或少的存在一些兼容性问题。
于是乎，干脆自己动手对这些常用的手势事件进行了封装，由于没有太多真实的设备来进行测试，可能存在一些兼容性问题，下面的代码也只是在 iOS 7、Andorid 4 上的一些比较常见的浏览器中测试通过。
tap 事件相当于 pc 浏览器中的 click 效果，虽然在触屏设备上 click 事件仍然可用，但是在很多设备上，click 会存在一些延迟，如果想要快速响应的 “click” 事件，需要借助 touch 事件来实现。
之前有写过一篇非等宽图片列表的布局的博文，那只是这种布局之前的叫法，为了和常规的等宽瀑布流布局做区分，根据这种布局的特性（整行是等高的），那么就叫等高瀑布流布局吧。
怎么又拿这种布局出来说事？最近几天在对以前开发的360图片搜索结果列表页的图片尺寸和交互效果做一些细节上的调整。同时也对布局的算法做了优化，之前采用的是以宽度裁切为主和夹杂着一些等比缩放的算法，当时是为了让每一行看起来高度都一致。由于宽度裁切的效果会让图片左右边缘部分有损失，而且当时也有图片 hover 时的放大效果在一定程度上弥补了这种损失。这次放弃了宽度裁切，也去掉了 hover 时放大图片的效果，全部采用了等比缩放的算法。
在上一篇博文中谈到的等比缩放的算法其实并不是最优的，还是会有一定的上下或者左右的裁切。研究了一下 Google+ 的相册使用的等高瀑布流布局的缩放，发觉还有一种更优的缩放计算的算法，于是花了两个小时将这种算法推演了出来。这里先检讨下，由于智商上的缺陷，数学绝对是我的弱项，这种算法比之前的要简单得多，之前是走了弯路了。
虽然之前有写过模拟浏览器拖拽行为的组件，但这种拖拽仅限于改变 DOM 元素的位置，只是 UI 层面的交互效果。最近在做的拖拽上传文件，拖拽时需要和服务端进行数据层面的交互，此时就需要用到浏览器原生的拖拽事件。
在高级浏览器中，DOM 元素都有一个 draggable 属性，用于标记其是否可以在浏览器中拖拽，常见的 a 、img 元素的 draggable 默认值为 true，浏览器默认其是可以拖拽的，而其他的布局元素如 div、p 这些默认并不支持拖拽，所以值是 false，如果想让其可以拖动，需要先将其设置成 true。
再来看看原生的拖拽相关的事件类型：
很多 WEB 开发者可能都会碰到这种头痛的问题，就是当用户对页面进行缩小或放大时，原本好好的布局就被破坏了。如果让网页支持自适应的缩小和放大布局，对于开发者来说是一个不小的挑战。
在我看来如果用户有意识的去对网页进行缩放，那么就应该知道缩放会破坏布局。还有很多用户其实压根不知道自己是何时对网页进行了缩放，此时就需要提醒用户应该将浏览器的缩放级别重置成默认的比例。
说到浏览器的缩放检测，可能有好几种方法都可以实现，从检测 CSS 样式到检测 Flash 的尺寸，可以说是各显神通，但我都觉得有点麻烦。其实还有更简便的方法的，当然各个浏览器的检测方法又有不同，对于 IE6，就直接无视了，因为 IE6 只能对文本进行缩放。
先来说说浏览器提供的标准检测接口，window.devicePixelRatio 是设备上物理像素和设备独立像素的比例，该属性就可以用于检测网页是否被缩放了。在普通的 PC 浏览器上，在默认无缩放的情况下其默认值是 1。可惜这么方便的属性目前只有 Firefox 支持。
见某网站的输入框支持截屏粘贴的功能，觉得有点意思，于是将代码扒出来分享下。
可惜，目前仅有高版本的 Chrome 浏览器支持这样直接粘贴，其他浏览器目前为止还无法粘贴( IE11没测试过 )，当然这种增强型的用户体验功能有总比没有好。
输入框的结构代码：
<input type="text" id="testInput" />
为输入框绑定粘贴事件：
var input = document.getElementById( 'testInput' );
input.addEventListener( 'paste', function( event ){
// dosomething...
});