浏览器在Html控制上通常会自动实现对于触摸交互的适当响应-所以,比如,Html5Range控制只会在你使用触摸交互的时候起作用.然而,如果你已经实现了自己的控制,它们可能不会响应点击拖动类型的交互;实际上,一些通用的类库(比如jQueryUI)还没有像这样实现本地化的支持触摸交互（尽管jQueryUI提供了像“猴子补丁”一样的修补来解决这个问题）.这是我在升级我的Web Audio Playgroud应用来支持触摸事件时遇到的第一个问题-滑动条是基于jQueryUI的,所以它们不支持点击拖动交互.我切换成HTML5 Range控制,然后就可以了.当然,我简单地添加了触摸移动处理程序来升级滑动条,但是还有一个问题...

3:触摸移动和鼠标移动不是同一件事

我曾经见过一些开发者陷入的一个误区就是：让触摸移动和鼠标移动的处理器调用相同的代码.这些事件的行为非常相近,但存在细微的不同-特别是,触摸事件总是以触摸发生时所在的元素为目标，然而鼠标事件则以当前位于鼠标指针下方的元素为目标.这就是为什么我们有鼠标移上和鼠标移出事件，却没有响应的触摸移上和触摸移出事件,只有触摸事件.

对此最常见的刺痛你的方式就是如果你碰巧移除（或者重新定位）某个用户刚开始触摸的元素.比如,假设一个图像切换模块中有一个触摸处理器来支持特定的滚动行为.随着现有图片的变更,你移除了一些元素，并添加了新的元素.如果用户碰巧开始触摸在其中的一张图片上,然后你又移除了它，你的处理器（作用于图片元素的祖先元素）将停止接收触摸事件（因为它们被分配到了一个当前DOM树中不存在的目标上）-那么看起来将是用户正把手指放在一个位置，尽管这个位置的元素已经移动了并且最后被移除了.

当然，你可以通过避免移除触摸事件开始时已经绑定触摸处理器的元素（或者祖先元素已经绑定处理器的元素）.或者,最好的方式是先不注册touchend或者touchmove处理器，一直等到获得了touchstart事件，然后为touchstart事件的目标元素添加touchmove/touchend/touchcancel处理器（然后在end/cancel事件发生时移除这些处理器）.这样你就可以一直接收触摸事件，即使目标元素移动了或者被移除了.你可以在这里尝试-触摸红色的方框然后点击将它从DOM中移除.

4:触摸和:Hover

鼠标指针把光标位置和动态选择区分开来,这使得开发者可以使用“移上”状态来隐藏和显示跟用户相关的信息.然而，很多触摸接口当前都不能检测到手指“悬浮”在某个目标上面-所以，通过这种方式提供重要的语义信息（比如，提供“这个控制是什么?”弹出层）是不可行的,除非你提供了一种触摸友好的方式来提供信息.对于如何使用hovering来向用户展示信息你需要谨慎.

然而，足够有趣的是, CSS的:hover伪类在某些情况下可以通过触摸触发-轻巧某个元素使其具有：hover状态时当手指按下的时候，它也获得了:hover状态.(在IE中,:hover只有当用户的手指按下的时候才起作用,其他浏览器中:hover被一直保持有效直到下一次敲打或者鼠标移动)这是一种在触摸接口中实现弹出菜单的有效方式-副作用就在于此时:hover状态也触发了.例如:

This is an awesome picture of me

一旦另一个元素被敲击，当前元素就不在处于活跃状态，hover状态也会消失，就像用户使用鼠标时将鼠标指针移到了元素外面一样.你可能也希望把内容包裹在一个元素中来实现制表位的效果，那样用户可以通过鼠标移上或者点击，触摸敲击或者键盘按下来显示或者隐藏额外信息，而不需要Javascript控制.当我开始让我的Web Audio Playground能够使用触摸接口时，弹出菜单已经能够很好的响应触摸事件的时候我很高兴，因为我已经用过这种结构了!

上面的方式在基于鼠标指针的接口和触摸接口中都能够很好的工作.这与"title"是相比较而言的，它在元素被激活的时候将不会显示出来:

其他的一些你可能会考虑的类似hover的语法:

把“touch”和"hold"实现为"次要点击".在很多设备上-移动或者台式-touch和hold已经被用来实现上下文菜单,所以你不需要使用自己的定时器-监听oncontextmenu时间,另外要确保取消默认的行为

将UI设计成接收两次单独的触摸事件来实现点击事件-第一次点击将显示hover信息，第二次点击才完成整个动作.

如果你正在实现hover效果来作为提供帮助信息（类似"这个控制项的是干什么用的"）的一种方式.你可能希望提供一种“帮助风格”来开关这种行为.

5:触摸精度vs.鼠标精度

鼠标跟现实中的老鼠在概念上是分离的,区别在于他们非常精确,因为底层操作系统通常会追踪指针的精确像素精度.移动开发者另一方面已经知道手指在触摸屏上的触摸并不如此准确,主要是由于跟屏幕交互时手指表面积的尺寸太大（部分原因是由于你的手指挡住了屏幕）.

很多个人和公司都对如何设计能够容纳基于手指交互的应用和网站进行了大量的用户研究,很多书也是关于这个话题的.基本的意见就是通过增加填补空间(padding)来增加目标对象的尺寸,然后通过增加元素之间的间距(margin)来降低错误敲击的可能性.(Margins不包含在处理触摸和点击事件的敲击检测中,padding却包含在这其中)对于Web Audio Playground系统一个主要的修补工作就是增加连接点的尺寸，这样他们就能够更准确的被触摸.

很多浏览器厂商在处理基于触摸接口的时候也进入了逻辑来帮助在用户触摸屏幕时准确定位目标元素，同时降错误点击的可能性-尽管这样做通常修正的是点击事件，而不是移动事件（尽管IE好像也修改了mousedown/mousemove/mouseup事件）.

6:有限的使用触控处理器,否则滚屏会卡顿

把你的触控处理器限制在你需要他们的地方也很重要;触控元素可能非常消耗带宽，所以滚动屏幕的时候要尽量避免引发触控处理器（因为你的触控处理器可能会干扰到浏览器滚屏优化-现代的浏览器会试着用显卡线程来处理屏幕滚动，但如果他们每次都要检查javascript来知道是否有事件需要被app处理，那基本上这个优化就废了。).你可以试试这里的浏览器行为的一个示例.

一条避免这个问题的技巧就是只在你的ui中很小一部分使用触控事件处理器,把你的触控处理器放在这里(比如，不要放在整个页面的body标签里。);简而言之，尽可能的限制你的触控处理器的使用范围.

7:多点触控

最后一件有趣而又具有挑战性的事是，尽管我们称之为“触控”用户界面，几乎所有的支持都是多点触控的，也就是说应用程序接口支持每次不止一次触控输入。当你准备在你的应用中支持触控时，你应该考虑多点触控会如何影响你的应用程序。

如果你开发了主要靠鼠标驱动的程序的话，那么你会习惯于用至多一个光标点的系统建立，它不会典型地支持多个光标。对于大多数应用，你将会仅仅把触控事件映射到一个单独的光标接口，但是，我们见过的大多数桌面触控输入软件可以处理至少2次同时的输入，而且大多数新的软件似乎支持至少5次同时的输入。比如说开发屏幕钢琴按键，你要能够支持同时的