今天我会和大家谈论4件事情：
首先会是key事件（按键事件），因为在这里存在很多的困惑，很多是关于他们如何工作的困惑。
然后我会谈谈change事件，他是我很喜欢的一个事件，不幸的是，它的工作情况有些乱。
第三，我会谈谈委派focus事件，当然可能你已经知道了。委派的事件通常只会触发在鼠标或者是键盘事件上，但是我找到了一种办法使它也能够使用在focus上面。
最后我会说说手机上面的事件，相当诡异的东西。。。

那么首先就来看看键盘事件吧，键盘事件有三个：keydown，keypress和keyup。大多数的人都认为自己很清楚他们在会何时触发，而我在这里要告诉你，其实未必就如你所想的那样。
我们先来看看定义，、
keydown事件：当用户按下键盘上面的一个键时会触发，用户一直按着这个键他就会持续触发。
keypress事件：有一点点的不同，用户按着一个字符键（原文是character key）才触发，就是说用户按了一个能在屏幕上输出字符的按键keypress事件才会触发，比如我们往一个textarea里面输入字符。
keyup事件：很简单，当我们释放一个按键时候会触发。
举一个例子，这样你能更明白些
比方说我按下了一个字母“o”键或是字母“i”键，那么keydown和keypress就都会触发，而当我按下的是一个特殊的按键比如是shift键，那么kyedown会触发，而keypress不会。
keydown和keypress的这种区别最初是由微软提出的，所有的ie都支持这种区分方式，一年前（08年吧）推出的safari3.1也适用这样 的方式，不过这只是说明了keydown和keypress存在方式的不同。相比较，firefox和opera会同时触发多个事件，因为此时事件既是一 个keydown事件又是一个keypress事件，所以我们应该会同时触发多个事件。这样很好，但是这样却无法解释为什么要同时存在两种事件、而不是一 种（keydown）。所以其实我还是很喜欢微软的这种区分的。
好吧，我们再来重温一次概念，keydown会在任何键按下时触发，keypress只是在字符键按下时触发，以上是在ie和safari下的情况，另外，我目前没有google chrome，不过他和safari很相近，所以这个应该也适用于chrome浏览器。

OK，让我们来看一些实际问题，通常我们都会写一段脚本来检测用户按过哪个按钮，然后利用这样的结果做一些有趣的交互应用。

键盘事件拥有两个属性，keyCode和CharCode，他们之间有一些不一样之处。keyCode表示用户按下键的实际的编码，而charCode是指用户按下字符的编码。
因此，当我按下“a键”，我会得到keyCode 65和字母a的charCode 97（注意是小写的字母哦），而当我按下shift键，我会得到keyCode 16，而我不会得到任何的charCode，因为按shift并没输入任何的字符。就这样，很简单吧~~~
我们现在得到两个属性了，两个属性各自包含了各种的信息，这真是好事~~~

但是接下来我们又遇到问题了，很复杂，无法解释但它就是这样的问题。keyCode属性。在keyDown事件里面，事件包含了keyCode – 用户按下的按键的物理编码。在Onkeypress里，keyCode包含了字符编码，即表示字符的ASCII码。这样的形式适用于所有的浏览器 – 除了火狐，它在onkeypress的时候keyCode返回数字0， 别问我为什么，它就这样。然后，火狐在Onkeydown中charCode返回数字0，在 onkeypress里，由charCode返回字符ASCII编码。而这个，只会在Firefox和Safari工作，因为他们是唯一支持 charCode的浏览器。（这一段翻译感谢信息学院的AN同学的纠正）

让我们更进一步看点更实际的东西，如果你想获取用户实际敲击的按钮，用keyDown事件来获取事件对象，并获取keyCode，这在所有浏览器都 行的通。另一方面，如果你想获取用户输入的字符，那么就使用keypress来获取，然后获取charCode（火狐和safari）或是 keyCode（其他浏览器）。

然后，我想有时候你也会有阻止某个按钮默认行为的想法，很常见的是方向键
设想你有一个适合于键盘的拖拽菜单，你希望用户用方向键来实现一个拖拽的操作，因此你就要取消方向键的默认行为（使页面向上或是向下滚动），那么一般来说 你就会在keyDown事件里面做这件事，因为如我所说的那样----keyDown会在一个按钮被按下时候触发，而keyPress只是在字符键按下时 触发，但是很不幸，这样子在opera行不通（当然我得承认我没有测试最新版的opera，也许现在已经修复了这个问题？待测试）。因此，我今天不会讨论 在opera下面阻止方向键的方法，很坦诚的说，我还没有一个答案。

这就是键盘事件的一些总结，不会很麻烦吧？我说了几种键盘事件，但是你得注意keydown和keypress的差别。

好了好了，来说说change事件吧。照理论说，change事件应该是很好的一个事件，因为他应该是在表单有变化的时候触发。比如，你想在表单提 交时检测一些用户操作表单的事情，比如是检测和验证用户在各个域的输入。当然也有很多时候我们会动态创建一个表单或是表单域或是选框--这样的表单会和用 户之间产生很复杂的交互，这时候我们就要知道用户什么时候对表单作了修改，从理论上说，change事件是最合适不过的了。

但是通常，我们总是会被迫去使用focus和blur事件或者是click事件去做检测表单变化的事，而不是用change事件。这是因为change事件不总是能很正常的运行着。我们分三种情况来讨论
1、文本框的变化事件（text field）
2、选择框的变化事件（select box）
3、复选框和单选框的变化事件

从文本框开始说吧，假设用户把焦点移动到了文本框上面（或用鼠标或用键盘的方式），之后又移去了焦点，比如说他进入了下一个文本框的输入。在这样的 情况下，change事件不触发，因为没有什么东西改变了---注意，第一个文本框的值并没有改变。但是我们对上述事情稍稍做一些变化，如果我们说，用户 点击了文本框，并输入了一些文本，然后再撤去焦点，这就触发了change事件，很好，他在所有浏览器中都如此工作。

然而，当我们使用selectbox的时候问题就来了，选择框事件是你可以想到的最古老的浏览器事件，我想大约在95、96年我们在浏览器中就有了 selectbox了，他可能列出了漂亮的链接，并节省了页面的空间。我们已经使用选择框有很长一段时间了，你也可以用鼠标去做一个选择。首先你点击选择 框，它便列出了选项，当你再次单击里面的一个选项时，就触发了change事件。因为浏览器知道：“ok，用户已经改变了选择框里面的值了”。这也是用于 所有的浏览器。

但是，用户还可以用键盘来操作改变选择框（select）的值，这就为我们使用change事件带来了麻烦。首先用户会把焦点移动到 selectBox上面，然后利用方向键来选择他需要的选项。这还不是什么问题，但是这种情况，在IE和opera下面，每当用户按一次方向键（切换选 项），change事件就会触发一次。这明显是很大的一个问题，如果一个选项表有20个选项，那么用户从第一个选项移到最后一个就会触发19次 change事件，这可以说是ie和opera很严重的一个bug。
而在firefox和safari里面，他们所做的工作就是，允许用户在选项之间用上下键来选择，然后会在用户blur这个选择框的时候触发change 事件，通俗的说，你告诉浏览器，我已经选择好了，浏览器你可以用change事件看看我是不是做了改变----像firefox和safari这样的工作 方式很好很正确。不过，在IE下面做一些类似于选框导航的工作，当用户用键盘来操作，使用change事件就很容易产生问题。这就是我们对于change 事件的首个大问题。

不幸的事继续发生，当我们在复选和单选框上面使用change事件，情况会更糟，我以一个复选框为例，基本上他和单选的工作方式一样。当用户点击了 复选框（我不仅仅指用鼠标点选），一个点选操作可以通过鼠标或是键盘来达到。总之，这样的一个点击使得复选框的值发生了变化---true or false。按常理这时候change就发生了，因为用户确确实实的改变了东西，这样的一件事也的的确确会在firefox，safari，opera里 面发生，但是IE不会。
IE到底怎么了？你点击了复选框而什么也没有发生。接下来呢，你用鼠标或是键盘把焦点移出这个复选框移到别的复选框上面，原来的这个复选框的blur事件 就触发了，同时change事件随之触发。这样的情况对于一些整理表格的操作实现来说是很糟糕的，比如通过复选框来开启表单的隐藏选项，在IE下面你只能 在blur一个复选框的时候开启隐藏选项，这样对于用户来说是很困惑的（因为会给用户带来一种滞后的感觉）。这也是IE下面一个很严重的bug。

你可以看到我在ppt上面给W3C也划了一个叉号，因为据我所知w3c的事件标准只是规定了blur，根据标准，一个change事件应该在一个表 单域改变并被移去焦点时发生。现在我们可以总结一下，change在文本域里面工作的很不错，当我们用键盘操作select框是它很有意义，而对于单选框 和复选框或者是你用鼠标操作select框change事件使用的意义就不太大。（我作为翻译认为这里ppk出现了口误，把鼠标和键盘操作 selectbox的情况说反了，大家要看了欢迎纠正，另外ppk貌似也没有提到用鼠标scroll方式操作select框的值的方式）

这就是我们目前遇到的一个问题，而我目前还没有找到一个很好的解决方式。幸运的是，我们可以用click事件或是focus事件或是blur事件做 一些弥补，虽然这不会花费太多的精力，但是我还是期望change事件能变得真正的实用。这样我们可以比较统一的用一个事件去侦测一个表单里面的变化并做 一些有意思的事。目前这还是我们能期待的。

进入我们今天的第三个话题吧，事件委派（event delegation），我非常确信你（指yahoo的同学们）应该已经知道什么是事件委派，不过其他的人却不知道，我简单的介绍一下。基本来说，事件委 派是减少定义事件处理的一种方式，我们用下拉菜单为例。用传统的方式，我们可能要对这个下拉菜单添加很多的事件处理函数，当你的鼠标停留在父级菜单上 面，1级子菜单弹出，我们在移动鼠标到1级菜单上面，二级菜单又会出来。而当我们使用事件委派时情况就有所不同，事件委派利用了事件的冒泡，当用户移动鼠 标到一个链接（link）上面，触发了链接的mouseover事件，同时通过冒泡mouseover事件冒泡到了链接的上一级元素，直至冒泡到整个文档 上面，这个过程会触发链接（link）上级任何一个含有mouseover事件的元素的mouseover事件，比如会冒泡到li和ul的 mouseover事件，那我们为什么不把处理事件的函数放在链接的上层呢？这样可以节省众多链接的事件处理函数的绑定。

曾经我的一个客户抱怨他的站点有点慢，尤其是在IE下面，于是我看了源代码，我发现他的下拉菜单有六七十甚至更多的链接，每一个链接绑定了自己的mouseover、mousedown、mouseout事件，这就使得页面变得缓慢了。
因为每一个浏览器都会为单独的事件处理开辟一个单独的内存，更何况是IE（拥有内存泄露的美名）。于是我告诉我的客户事件委派，然后。。。。（网页快起来了）

那么首先让我们来建立一个下拉菜单

我们首先把我们的mouseover和mouseout事件处理函数绑定到ul上面，这在所有浏览器中都行的通。

不过如果一个用户不用鼠标，而是想用键盘操作打开这个下拉菜单，我们又该怎么做呢？这个问题有个我们带来了一个重要的主题，设备的独立性（让网页支持多种设备的操作）。这也是我想向大家解说的，我们做的东西要兼容各种设备。
基本的规则是，所有带有“mouse”在名字里面的事件，只是在你真正使用鼠标的时候工作。听起来很简单吧，不过这总会被很多人忽视。因此，我们需要用户 使用键盘的时候能告诉我们用户何时是鼠标移入何时又是鼠标移出的事件，那么目前看最合适不过的就是focus和blur事件。因此，如果事件通过鼠标 mouseover或是键盘focus冒泡到上面的元素，冒泡到达ul时我们就执行目标函数展开菜单。当鼠标mouseout或者是键盘blur冒泡上去 时，我们就执行关闭菜单的函数。但是问题在于，这不可行，因为focus和blur事件不会冒泡。

这就带给我们另一个问题，什么事件支持冒泡？什么事件又不支持冒泡？我们先把事件分为两类：一类是设备事件（鼠标或是键盘按键事件），另一类是界面事件。

鼠标和键盘事件是在使用输入设备的时候触发的，我还在做一个更好的定义，不过基本是这个意思，基本上用户所作的就是点击鼠标按键、点击键盘按键、移 动鼠标或其他的一些事，总之是和一个具体的外接设备相关的，这些事件的例子 如，mouseout，mouseover，click，keydown，keypress，顺便说一声click是唯一既迟滞鼠标触发又支持键盘触发的 事件：你用鼠标点击会触发click，用键盘tab移动焦点到目标然后回车也会触发click。click是很少的能够工作于多种设备下的事件。因此，一 个click事件是很安全的。其他的一些设备事件总是只支持某一个设备，最后要说的，就是以上提及的这些事件支持冒泡，直到document级。

界面事件，在一个常规事件触发时执行，而不关注它是如何被触发的（翻译的有点生涩，欢迎提意见）
界面事件的一个比较好的例子是，表单的submit事件，当一个表单被提交他就会触发，而表单submit事件并不关心用户是用什么方式来提交表单的，可 以使用户用鼠标点击了提交按钮提交表单，可以是用户输入文本按了回车提交表单，只要是提交了表单，submit事件就会触发。这类事件还有很多，又如 onload，onupload，change，focus，blur，对了这里有我们苦苦追寻的focus和blur事件。因为我们希望我们的下拉菜单 能够兼容多种设备。

大体来说，界面事件不支持冒泡，对我们来说这真是一个不好的消息，因为如果我们想让键盘用户也能用我们的下拉菜单，我们就要用到focus和 blur。但是focus和blur并不能冒泡上ul元素，我们就只能老老实实的把事件处理绑定在每一个li上面了。当然还有一个不算好消息的好消息，我 们可以在事件捕获中得到focus和blur，事件捕获的工作是和事件冒泡相反的，但是它在IE下不被支持。。。不过我们一会儿会讨论IE。

我们说事件冒泡，我们点击了a元素，a的click执行，然后事件冒泡到了li，之后是ul，之后是document。事件捕获则是，在我们点击了 a之后，事件从document一级级的下来，经过ul、li、然后才到达a并终止捕获。你会觉得冒泡和捕获这两个东西用哪个都差不多，不过当我向 dean Edwards问了这个问题后，他说：“不不不，你应该在大多数情况下去使用事件捕获”。

当你要捕获一个focus事件，被绑定在目标元素的祖先元素上的事件就会被执行，这个可以在所有浏览器下使用，当然除了IE，因为它不支持事件捕 获。因此基本来说，如果我们把焦点移上a元素上并同时使用事件冒泡，只有a链接的unfocus事件会被触发。但是我们反过来使用事件捕获，那么这个 unfocus事件就会顺着document->ul->li的顺序执行下去。

为什么事件捕获和事件冒泡会有差别？我也说不出。这只是我测试出来的，我开始在opera里面测试，开始我以为他只是opera特有的，但是我在 firefox下面也测试，哦？火狐也有这个特性，然后又测试了safari，呵呵，safari也有同样的表现，最后，我发现它几乎是一个跨浏览器的特 性。这样让我觉得事件冒泡和事件捕获具有同样的作用，因为在我之前的感觉中，事件是否能被捕获并不最重要，但是能否冒泡就不一样了（能否被冒泡意义重 大）。不管怎么说，目前的这种状况（应该是说冒泡和捕获的混乱的支持情况）意义不是很大，但他确实能解决很实际的问题，因为现在我们可以对focus和 blur进行事件委派了。

我们要做的很简单，我们给根元素添加上addEventListener，并给这个函数的最后一个参数设为true，使其工作在捕获阶段。

这样，一旦下拉菜单有focus事件发生，那么ul上面的事件捕获就会触发，绑定在上面的this.mouseOver函数就会被执行。别问why，他就是这样工作的。

当然，因为IE不支持事件捕获，我们还要添加一点点东西，做一些修改，IE虽不支持事件捕获但是他有自己的解决方案，这是IE所特有的。

IE带有两个类似于focus和blur的事件，但唯一的区别就在于他们支持冒泡，他们是focusin和focusout，我们给原来的代码添加 上两行，dropdown.onfocusin, and dropdown.onfocusout。这样我们的事件委派就工作在了所有的浏览器中。

顺便说一声，YUI团队已经把这种特性纳入了他们的库之中，不过当你使用其他的一些库的时候，这样的技巧你也可以记一下以便必要时候用得到，这样的技巧很好，但是IE并不是总能提供类似于focusin和focusout这样的东西，所以那种时候你可能会抓狂。