See section 7B of the book.
On this page I give a quick overview of the most important events, including compatibility information for modern browsers.
All events named on this page are recognized by most browsers when they occur on certain HTML elements. This means that the browser looks if any event handling script is registered to the HTML element for this event. If there is such a script, it is executed immediately.
In the beginning there were only a few events. These events work in almost all JavaScript browsers, even in very old ones. Note that in those early days events worked on links and form fields, sometimes on then entire window, but not on many other HTML elements.
Much has changed since the olden days, many new events were introduced. Most Version 4 and higher browsers allow events to be registered on almost any HTML element.
So you can detect pretty much any event on pretty much anything, though a keydown
event on a P doesn't have much meaning.
See the Events quick compatibility overview for the complete list of events and their browser compatibility.
Interface events are events that are not caused by user actions, but by the result
of user actions.
When the user clicks on any element he always causes a click event. When
clicking on the element has special meaning, an additional interface event is caused.
For instance, when the user clicks on a link his action causes
a click event. Clicking on a link orders a new page to be loaded, though, so the
result of this specific click event is the interface event unload.
Other interface events are resize, scroll and focus/blur.
From Netscape 2 onwards all browsers recognize two events on links.
When the user moves the mouse into the link area, the
mouseover event fires. When he clicks on it the click event
fires. Pretty soon after the mouseout event was added, which fires when the mouse
leaves the link area. Thus the Traditional Triad of mouse events was formed.
Since the Version 3 browsers mouse events have proliferated. dblclick was added and
the click event was split up into mousedown and mouseup:
user depresses and releases the mouse button.
Finally it became possible to follow the mousemove.
You'll find a detailed description of these events on the Mouse events page.
Forms recognize the submit and reset events, which — predictably —
fire when the user submits or resets a form. The submit event is the key of any
form validation script.
When the user submits the form, go through all form fields and see
if he has filled in correct data. If you spot a mistake, stop the form submission and alert the
user of the problem.
Form fields recognize the focus and blur events which fire when
the field receives or loses the focus, the Key events and the click event. See the other tables
for compatibility information.
In general you should be careful when you use these events. Although it's perfectly possible
to validate each form field onblur — when the user leaves it — it is generally
very annoying because most form validation routines make use of alerts. The user doesn't want
to see all kinds of stuff flashing up when he's busy filling in a form.
In its
DOM 2 Event specification W3C defines Mutation events. These
events fire when the DOM structure of a document is changed. The most general one is the
DOMSubtreeModified event which fires whenever anything happens to the DOM tree
below the HTML element.
Mozilla translates this as subtreemodified. Since even Mozilla doesn't yet support
it this site doesn't describe any other W3C events.
Microsoft has created extreme numbers of proprietary events. Some of them are interesting.
contextmenu event fires after the user requests
the context menu (right–click menu) by whatever means. It is much used – and much
abused. Mozilla also supports this event.readystatechange event serves as
a sort of load event. When the readyState of the XML document
becomes 4, the document has finished loading. (Don't ask me what readyState
is, it works, and that's enough)beforeunload event fires — surprise — just before the
unload. Its point is to allow canceling of the unloading of the page, but its
use is strongly deprecated.mouseenter and mouseleave, two events that are almost, but not quite,
equal to mouseover and mouseout. See the
mouse events page for a discussion.Of course these events are only supported by Explorer Windows.
Mozilla, too, has a large number of proprietary events. I haven't yet studied them in detail.
All these events are detected by the browser whenever they take place. The browser automatically performs default actions, like following a link when the user clicks on it. But otherwise nothing happens.
The point of event handling is that you can make something happen. You can define your own scripts for handling the event. If you do that your script is executed whever the event takes place. If the something that happens is useful or nice and happens in a logical way, your users will be glad of the extra interaction.
To make sure a script is executed when the event fires, you register it as an event handler for a certain event on a certain HTML element, like
<a href="somewhere.html" onClick="alert('I\'ve been clicked!')">
Now the script alert('I\'ve been clicked!') is executed whenever the click event
takes place on this link. It is registered as an event handler.
If you wish to go through all event pages in order, you should now continue with the Early event handlers page.