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.
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
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
Other interface events are
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
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
user depresses and releases the mouse button.
Finally it became possible to follow the
You'll find a detailed description of these events on the Mouse events page.
Forms recognize the
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
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.
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.
contextmenuevent 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.
readystatechangeevent serves as a sort of
loadevent. When the
readyStateof the XML document becomes 4, the document has finished loading. (Don't ask me what readyState is, it works, and that's enough)
beforeunloadevent fires — surprise — just before the
unload. Its point is to allow canceling of the unloading of the page, but its use is strongly deprecated.
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
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.