因此JavaScript 检测用户的操作,以便知道何时做出反应,反应时执行哪个 functions 。
当用户做出某操作就会触发一个 event 。也有一些 events 不是由用户直接触发: 例如 load
event 是页面加载时触发的。
JavaScript 可以检测一些 events。从 Netscape 2 开始就可以把事件处理程序( event handler)附加到某个HTML 元素。 事件处理程序会等候某个 event (例如 链接上的 click 事件 )发生。这时候就会执行你定义好的JavaScript 代码来处理事件 。
用户操作会产生一个 event。当 script 对 event做出响应,这就是所谓的交互。
假如没有事件处理机制,在页面中添加 JavaScript 就毫无意义。好的脚本可以对用户操作做出响应。因此网景发布第二版支持JavaScript的浏览器时,它也支持事件处理机制。
Netscape 2 只支持一些 events。Mouseover 和 mouseout 很快风靡,因为可以通过onMouseOver 改变 images ,通过onMouseOut 把它们变回去。在那个时候是很神奇的。也可以看到用户 submit 或 reset 表单,因此实现了客户端表单验证( form validation)。浏览器也可以检测表单获得焦点、失去焦点、页面加载完成、开始上传等。尽管现在看来很稀松平常,但是在那个年代,这可是Web页面革命性的进展。真正的交互成为了可能,因为你可以对用户操作做出响应。
最古老的事件处理就下面一样:
<a href="somewhere.html" onclick="alert(‘I\‘ve been clicked!‘)">
这种最古老的事件处理机制实际上是由 Netscape 定义的标准。如果想要JavaScript工作,其他的浏览器包括IE都得遵从Netscape 2和3的处理事件的标准。因此这些最古老的事件和事件处理程序在任何JavaScript浏览器中都能很好地运行。
然而,自从引进这些简单的事件处理器后很多东西都发生了变化。首先事件数量增加,同时,事件注册机制也发生了变化。现在可以完全由JavaScript来设置。不再需要大量的附着于代码之上,你可以写一些很简单的代码来设置所有的事件处理程序。
第4版的浏览器还提供了更多的关于事件本身的信息。光标在哪儿(光标在撒钱)?事件何时触发?有没有键被按? 如果该界面元素存在父子元素,而且父子元素也定义了同样的事件,这个时候事件该如何处理呢,事件在父子元素之间是如何传递的呢,谁会先接收到这个事件,又是谁先处理呢?不同的浏览器其处理机制也不尽相同。
在网景和微软斗争的年代,两个公司选择了完全不同的事件模型。W3C非常理智的处理了这种差异,在两者之间采取了中和的方法 DOM Event specification。除了一个严重漏洞( serious flaw), W3C的模型, 添加了很多新功能并解决了旧模型的很多问题。
三个模型意味着事件处理机制在不同的浏览器中可能有所不同。
就像 DHTML,
W3C DOM 或其他的高级脚本技术一样,我们必须在浏览器中小心翼翼地执行代码。
在 Explorer 中调用 stopPropagation()
或者在 Netscape调用 srcElement
将会导致严重的错误甚至导致脚本不可用。因此在使用之前,我们必须确保浏览器支持该方法或该属性(
the methods or properties) 。
如下一个简单的代码分支
if (Netscape) { use Netscape model } else if (Explorer) { use Microsoft model }
只是一个近似的解决方案,因为它忽略了非主流的浏览器。现在的解决方案可以处理大量的 modern event handling,除非你的脚本机智地设定非主流浏览器不允许执行代码,因为它们不是 Netscape 或 Explorer。
所有其他非主流的浏览器都必须做出决定站在哪一队:支持哪一种模型。Konqueror/Safari, 选择了严格的标准并支持 W3C model。Opera and iCab 则比较谨慎,支持旧的 Netscape model 和 Microsoft model中的大部分。
但非主流的浏览器可能支持的是 Microsoft 标准,但实际上其事件属性既有 W3C 的也有 old Netscape model的。
首先,千万不用使用 browser detect。这是最快的作死方法。任何代码如果使用navigator.userAgent来做事件模型的检测,那简直比没用还没用应该直接拉出去弹JJ。
其次,不要将 DHTML 对象检测(object
detection )与事件对象检测混为一谈。当书写DHTML 时我们通常这样检测是否支持DOM: if
(document.all)
is supported. 如果是酱紫,使用 Microsoft all
container 的脚本可以正常执行。
但 DHTML和事件处理程序有不同的浏览器兼容模式。例如: Opera 6 支持部分 W3C DOM 但不支持 W3C event model。因此在Opera中。所以代码使用 if
(document.layers)
或者其他的事件模型检测都是不正确的。
然后我们应该做些什么? 事件属性( event properties)引起严重的问题。如果我们使用大量特定对象检测,可以解决99%的浏览器的不兼容问题。只有鼠标位置( mouse position)非常的麻烦,其他的都比较简单了。
此外,最好是不去在意三个事件模型。相反,我们必须理解四个事件注册模型,两个事件访问模型和两个事件的命令。
事件处理和浏览器兼容性,参见事件兼容性表( event
compatibility tables)。
貌似很复杂,其实so easy。实际上,当我认识到要对不同事件模型单独处理之后,我才开始真正理解事件处理。 这都是关于如何提出正确的问题的。别这么问“如何写一个事件来处理脚本?” 这是个问题,但很难给出答案,你应该问得再具体一点,别人才好给出答案:
return false
, 默认的动作就会被阻止。该技术标准是由 Netscape 2 定义的,现在依然有效。All questions above will be treated on separate pages that give background information and the nuts and bolts of event handling.
The trick of writing cross–browser event handling scripts is not to use an overall event model check but to answer all these questions separately. You’ll find that you need to worry about browser compatibility mainly when reading out event properties.
First choose an event registration model, then make sure the event is accessed by all browsers, then read out the correct properties and then solve event order problems — if any occur. Thus you can solve each compatibility problem separately and ensure your code runs in all browsers that support advanced event handling.
If you wish to go through all event pages in order, you should now continue with the events page.
So how do you write an event handling script? On this page I give a quick overview for those who need fast answers and want to study the theory later.
The first step is registering your event handler. You have to make sure that the browser executes your script whenever the event you’ve chosen takes place.
There are four models for registering event handlers. inline, traditional, W3C and Microsoft.
It’s best to use the traditional model, since it is completely cross–browser compatible and gives much freedom and versatility. To register an event handler, do
element.onclick = doSomething; if (element.captureEvents) element.captureEvents(Event.CLICK);
Now the function doSomething()
is registered as the handler of the click
event of HTML element element
.
This means that whenever the user clicks on the element, doSomething() is executed.
When you’ve registered your event handler you start writing the actual script. Usually you want to access the event itself, so you can read out information about the event.
To access the event so that you can read out its properties, always start your event handling function thus:
function doSomething(e) { if (!e) var e = window.event // e refers to the event }
Now e
refers to the event in all browsers and you can access the event.
Sometimes you also want to access the HTML element the event took place on. There are two ways for doing this: using the this
keyword or using thetarget/srcElement
properties.
The safest way to access the HTML element is by using the this
keyword. this
doesn’t always refer to the correct
HTML element, but in combination with the traditional model it works fine.
function doSomething(e) { if (!e) var e = window.event // e refers to the event // this refers to the HTML element which currently handles the event // target/srcElement refer to the HTML element the event originally took place on }
The target/srcElement
properties contain a reference to the HTML element the event originally took place on. Very useful, but when the event is
captured or bubbles up the target/srcElement
doesn’t change: it’s still the element the event originally took place on. (See the Event
properties page for target/srcElement
, see the this page
for the this
keyword)
As to reading out interesting event properties, this is the area with the worst browser incompatibilities. Study the event compatibility tables and write your own script to read out the information you need.
Be sure to always use the most detailed object detection possible. First check if each property exists, then read out its value. For instance:
function doSomething(e) { if (!e) var e = window.event if (e.keyCode) code = e.keyCode; else if (e.which) code = e.which; }
Now code
contains the pressed key in all browsers.
Finally, you have to decide whether you want the events to bubble up. If you don’t want that to happen, stop the propagation of the event.
function doSomething(e) { if (!e) var e = window.event // handle event e.cancelBubble = true; if (e.stopPropagation) e.stopPropagation(); }
Now you can start actually writing the event handling script. Use the information the previous snippets of code give you to decide what actually happened when the event took place and how your script should react to it. Remember: keep the interaction logical or your users won’t understand what’s happening.
原文地址:http://blog.csdn.net/chenmoquan/article/details/41843669