首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 网站开发 > Web前端 >

转载一篇关于浏览器事件的一些述说

2012-08-26 
转载一篇关于浏览器事件的一些陈述文章出处:http://www.zipeng.info/archives/ppk-on-js-events.html? kun

转载一篇关于浏览器事件的一些陈述

文章出处:http://www.zipeng.info/archives/ppk-on-js-events.html? kun的记事本

?

那么今天我会和大家谈论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(拥有内存泄露的美名)。于是我告诉我的客户事件委派,然后。。。。(网页快起来了)

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

var dropdown = {    init: function (dropdown) {        dropdown.onmouseover = this.mouseOver;        dropdown.onmouseout = this.mouseOut;        if (dropdown.addEventListener) {            dropdown.addEventListener('focus',this.mouseOver,true);            dropdown.addEventListener('blur',this.mouseOut,true);        }        dropdown.onfocusin = this.mouseOver;        dropdown.onfocusout = this.mouseOut;    }
?

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

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

另附:PPK的一些关于事件的文章
this关键字传统事件注册高级事件注册方式

?

?

热点排行