History of JavaScript Event System

A Complete Event System usually has the following three roles:

• Event object, used to store the event status.
• Event source object, the object of the current event in operation, such as element node, Document Object, window object, XMLHTTPRequest object, etc.
• Event listener. When an event source generates an event object, it calls the corresponding callback function for operations. In ie, the event object is always the separation of window. event in the global attribute.

When W3C did not introduce its dom model into the web page, Netscape and Microsoft were no longer forced to get involved with the relevant Dom model in a language they were familiar. In fact, it is strange that the father of JavaScript is busy copying other languages and ignoring the construction of its own event system. Since then, the world has been divided into two camps.

In the dom0 era, Dom here refers to W3C Dom. Both parties have designed two methods to bind events, no intrusion or intrusion. You can say the difference between inline and non-inline.

Intrusive, the same for both parties. There is no way. It was implemented very early. At that time, ie had only copied copies and did not dare to make a fuss.

 
<Input name = "Ruby" onclick = "alert (this. NAM)"/>
 

Then there is no intrusion. It is estimated that they have completed their respective Dom models and implemented the indexing mechanism for element nodes. For example, the following webpage snippets are available:

We must locate this element node step by step from top to bottom to operate on it. Note that there was no such thing as document. getelementbyid. The webview method binds the relatedCodePut it in a script Tag:

<Form name = "form1"> <input type = "button" name = "button1" value = "aaaa"/> </form>
 

If you do not want to enclose the code block in window. onload = function () {}, you must put the script tag after the form element.

Microsoft also has an index mechanism, which is basically the same as that of Netscape. However, ie4 also introduces document. All and document. All. tags. However, there is another method for IE:

 
<Script for = "button1" event = "onclick" Language = "JavaScript"> alert ("This. AAA") </SCRIPT>
 

However, it cannot use this (or can, I won't), and it also requires a script tag to correspond to a tag in the body, which is a waste of resources and eventually eliminated.

This is the binding mechanism of dom0. In addition, the code written in the tag in the inline mode is actually equivalent to the following method:

<P id = "AA" onclick = "alert ('aaa')"> equivalent to callback </P> <SCRIPT type = "text/JavaScript"> var P = document. getelementbyid ("AA") p. onclick = new function ("alert ('aaa')") // equivalent to limit p. onclick = function () {alert ('aaa')} </SCRIPT>
 

So far, all three roles of the Event System have appeared. Objects obtained through the index mechanism (element nodes or something) act as event sources, onclick, onmousemove, and other event attributes. They act as listeners. The functions after onclick are callback functions, this is executed asynchronously.

With the rise of No intrusion, it should be called the separation of the presentation behavior structure in web standards. Write onclick or something in the tag. Non-Intrusive programming has a desire to allow more people to write more code. In the past, it was always in a tag. I always pay attention to the embedding of double quotation marks and single quotation marks at any time. I am tired of writing too much. I don't want to write any more. Now I don't have this limit, just like a horse that just gets rid of it, focus more on compatibility with more browsers and new ideas. Okay, it says, people begin to think that they can't bind two onclick events to the same element ?!

 
<SCRIPT type = "text/JavaScript"> var P = document. getelementbyid ("AA") p. onclick = function () {alert ('first time')} p. onclick = function () {alert ('second Time')} </SCRIPT>
 

Of course, we can only use the second alert. Of course, we can also use some techniques to achieve this purpose:

 
 can bind multiple functions of the same type 
  

<Br/> <! Doctype HTML> <br/> <HTML lang = "ZH-ch"> <br/> <pead> <br/> <meta charset = "UTF-8"/> <br/> <meta content = "Ie = 8" http-equiv = "X-UA-compatible"/> <br/> <title> bind multiple event objects by situ zhengmei </ title> <br/> <SCRIPT type = "text/JavaScript"> <br/> window. onload = function () {<br/> var P = document. getelementbyid ("AA") <br/> var addevent = function (El, type, FN) {<br/> var type = "on" + type <br/> var old = El [type]; <br/> If (Typeof El [type]! = 'Function') {<br/> El [type] = FN <br/>} else {<br/> El [type] = function () {<br/> old (); <br/> FN (); <br/>}< br/> addevent (p, "click", function () {alert ('second Time')}); <br/> addevent (P, "click", function () {alert ('third Time ')}); <br/>}< br/> </SCRIPT> </P> <p> </pead> <br/> <body> </P> <p id = "AA" onclick = "alert ('first time ') "> can bind multiple functions of the same type (Click me) </P> <br/> </body> <br/> </ptml> <br/>

Run code

However, this cannot be done for users, so browser vendors make them built-in. We also implemented an event stream, that is, to allow event objects to be transmitted between controls (TAGS. One set of ie apis is createeventobject, attachevent, dettachevent, and fireevent. The event stream is from bottom to top. I don't know about the set of Netscape, but I heard that W3C is also developed from it. The API is complicated, such as createevent, initevent, addeventlistener, removeeventlistener dispatchevent, and there are many versions of initevent, for example, initmouseevent and initkeyevent have many parameters for more precise configuration. Addeventlistener has three parameters, but the third parameter is usually only useful in the event proxy, usually false, consistent with IE, and bottom-up bubbling. Because W3C is inferior, it always wants to divide the line with IE, it can bubble up to window (ie is document ):

 
Event = Dom. Event (type); ARGs = [event]. Concat (ARGs); var parent = caller; while (! Event. ispropagationstopped () & parent) {// ispropagationstopped is a W3C DOM method, Dom. events. handle. apply (parent, argS); // determines whether bubble parent = parent has been disabled. parentnode | (parent! = Window) & window ;}
 

It is strange that the HTML parentnode is actually a Document Object. It would be a lot of trouble to capture it. Now let's take a look at compatibility issues when binding multiple events. For example, the above addevent is actually enough, And the addevent of De is also developed based on the dom0 event. However, some events cannot be simulated by dom0, such as FF's dommousescroll event. Because there is no ondommousescroll attribute, it must use addeventlistener, but IE, opera, chrome, and other supported mousewheel. Therefore, we still cannot leave these advanced APIs. A general addevent function:

 
VaR addevent = (function () {If (document. addeventlistener) {return function (El, type, FN) {el. addeventlistener (type, FN, false) ;};} else {return function (El, type, FN) {el. attachevent ('on' + type, function () {return fn. call (El, window. event );});}}})();
 

However, there is still a problem. The callback function bound to IE is not a first-in-first-out method. For details, see the issue of execution sequence of events binding between IE and non-ie browsers. Well, I will stay in the next part.

PS, this series is different from the Javascript cross-browser Event System Series, which focuses on various problems encountered in designing an event system. The latter provides specific solutions.