The events

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

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.

Mouse events

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.

Form events

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.

W3C events

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 events

Microsoft has created extreme numbers of proprietary events. Some of them are interesting.

Of course these events are only supported by Explorer Windows.

Mozilla events

Mozilla, too, has a large number of proprietary events. I haven't yet studied them in detail.

Event handlers

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.