简介

近三十年，桌面计算体验集中围绕在一个键盘与一个鼠标或轨迹板，以它们作为主要的用户输入设备。不过在过去十年间，智能手机和平板电脑带来了一个新的交互范式：触摸。通过引入触屏的Windows8机器，以及现今很酷的触摸式Chromebook Pixel笔记本的发布，触摸现已成为桌面体验的部分预期。最大的挑战之一是创造出不仅仅工作于触摸设备和鼠标设备的体验，还要创造出用户同时使用这两种输入方法的体验——有时候是同时的！

这篇文章将帮助你理解触摸功能是如何内置于浏览器的，怎样将这种新的界面机制集成到你已有的应用，以及触摸怎样才可以和鼠标输入和谐共存。

Web平台中的触摸状态

iPhone是第一个在web浏览器中植入了专用于触摸的API的流行平台。有些其它的浏览器制造方创建了类似的API接口，植入浏览器并与iOS的实现兼容，现在被描述为"触摸事件版本1"规范。触摸事件在桌面环境被Chrome和Firefox支持，在iOS环境被Safari支持，在Android环境被Android浏览器支持，还有其它的移动浏览器比如Blackberry浏览器。

我的同事Boris Smus写了一篇关于触摸事件的HTML5Rocks教程，如果你以前没有看过触摸事件，这仍然是一个很好的开始。事实上，如果你以前没有处理过触摸事件，在你继续以前，现在就去阅读那篇文章吧。你去吧，我等着。

结束了？现在你对触摸事件有了一些基础知识，写一个可触摸的交互的挑战在于，触摸交互与鼠标（以及仿真鼠标的轨迹板和轨迹球）事件极为不同——虽然典型的触摸接口试图在模仿鼠标，但这种模仿并不完美或者说完整；你确实需要处理这两种交互模式，而且可能会不得不单独的支持每一个接口。

最重要的是:用户或许有触屏和一个鼠标

许多开发人员创建的网站会静态的检测环境是否支持触摸事件，之后再假设他们只需支持触摸（不需要支持鼠标）事件。现在这是一个错误的假设——相反的，仅仅因为触摸事件的存在并不意味着用户主要使用的就是触摸输入设备。像Chromebook Pixel笔记本之类的设备以及一些Windows 8便携电脑现在已经可以同时支持鼠标与触摸式输入方法，在不久的未来还会有更多。在这些设备中，用户同时使用鼠标和触屏与应用交互是很自然的事情，所以“支持触屏”并不等于“不需要支持鼠标”。你不能将这个问题想成“我需要写两种不同的交互方式并且在它们之间切换”，你要想清楚这两种交互怎样独立的工作，也要想清楚怎样让它们协同工作。在我的Chromebook Pixel笔记本上，我经常使用轨迹板，但也会伸手触摸屏幕——在同一个应用或页面中，当时怎么感觉自然我就怎么做。从另一方面来说，有些触屏的便携式电脑用户几乎从不使用触屏——因此触摸输入的存在不应该禁止或者隐藏鼠标控制。

不幸的是,很难知道用户的浏览器器环境是否支持触摸输入,理想情况下,台式机上的浏览器应该显示对触摸事件的支持，这样就可以随时安装触摸屏显示器（例如：通过KVM连接触摸屏是否可行）.基于所有这些原因，您的应用不应该尝试在触摸和鼠标之间切换--只需要两种方式都支持.

指针事件

在Windows8系统的IE10浏览器中.微软引入了一种叫做指针事件的心的模型.指针事件是鼠标事件和触摸输入事件，还有其他输入方式比如笔输入的联合.将指针事件模型提交到W3C标准还有很多工作要做,在短时间内,已经有像PointerEvents和Hand.js这样的类库供你在代码中实现指针事件，从而避免为鼠标和触摸分别提供支持.为了更好的触摸和鼠标交互,你可能需要为鼠标和触摸事件分别自定义用户体验,但在很多情况下,统一事件处理都简化了这样的过程.然而,这种模型还面临着巨大的挑战,它需要支持冗余的输入模型,也还没有被广泛支持,而且还需要很多事件来将它变成一个稳定的,跨浏览器的标准.

与此同时,最好的建议是同时支持鼠标和触摸交互模型.同时支持触摸和鼠标事件还面临着很多挑战,所以这篇文章对这些挑战以及克服这些挑战的策略进行了分析。另外,有些建议只是一般的“实现触摸”的建议,所以，如果你已经熟悉了在移动环境中实现触摸,这可能是多余的.

同时支持鼠标和触屏

1-点击和轻拍-“自然的”事物的顺序

第一个问题是传统的触摸界面技术想要模仿鼠标的点击-很显然，在触屏技术应用到应用程序之前，是仅仅只能和鼠标事件进行交互的。你可以把这个作为一个快捷键使用-因为“点击”事件将会继续被淘汰，无论用户是用鼠标点击还是用手指轻敲屏幕。然而，这个快捷方式还有一些问题。

首先，你在设计先进的触屏交互技术的时候必须要很仔细。：当用户使用鼠标，它就会通过点击事件给出应答，但是当用户触摸屏幕的时候，触摸和点击事件都会发生。对于一个简单的点击事件，其顺序是：

1.触屏开始

2.触屏移动

3.触屏结束

4.鼠标悬停

5.鼠标移动

6.鼠标按下

7.鼠标弹起

8.点击

当然，这个也意味着如果你正在处理触屏事件，比如说触屏开始，你需要确定你没有在同时处理相应的鼠标按下以及/或是点击事件。如果你能取消这个触屏事件（在事件处理程序中访问perventDefault()方法）,然后在这次触屏中没有鼠标事件出现。其中触摸处理程序最重要的一个规则是：

使用事件处理程序中的perventDefault()方法，所以默认的鼠标仿真处理就不会发生。

然而，这样也限制了其他默认浏览器的的行为（像scrolling）-虽然通常你在你的处理程序中完全的处理触屏事件，并且你想要禁止默认的行为。一般来说，你要么去处理和取消所有触屏事件，要么避免有一个对应这个事件的处理程序。

其次，当用户在移动设备上触摸一个网页上的某个元素时，相对于鼠标事件(mousedown)处理，那些没有为移动设备交互做专门设计的网页处理touchstart事件会有一个至少300毫秒的延迟。若你身边有触控设备，可以试试这个example，看看这个延迟效果。或者，也可以使用Chrome，打开Chrome开发者工具中打开"Emulate touch events"，可以帮助你在非触控系统上测试触控接口。

这个延迟是用来给浏览器判定用户是否在采用其他的手势操作，特别是双点缩放。很明显，这个延迟在需要对手指点击做出瞬时相应时会引起问题。已经有个正在进行中的工作尝试对这些会由于延迟而引起问题的场景做出限制。

Chrome安卓版Android自带浏览器Opera安卓版Firefox安卓版Safari iOS

Non-scalable viewport无延迟300ms300ms无延迟300ms

No Viewport300ms300ms300ms300ms300ms

首选的最容易的避免这个延迟的方法是告诉移动端浏览器你的页面不需要缩放。这可以通过使用固定的viewport实现，例如向页面中插入下面的代码：

但上述做法并不会总是很合适。很明显，这种做法阻止了缩放，所以尽量少用（若你确实要阻止用户缩放，那么你可能要在你的应用中提供其他方法增强文本可阅读性）。同样的，对于支持触控的桌面设备，以及其他一些移动平台的浏览器而言，若碰上带有不可扩展的viewports，这个延时不再适用。

#2:鼠标移动事件不是通过触摸实现的

在这一点上,非常值得注意的是,通过触摸接口对于鼠标事件的仿真通常并不扩展到