The DOM Level 2 Event Model is designed with two main goals. The first goal is the design of a generic event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event. Additionally, the specification will provide standard sets of events for user interface control and document mutation notifications, including defined contextual information for each of these event sets.
The second goal of the event model is to provide a common subset of the current event systems used in DOM Level 0 browsers. This is intended to foster interoperability of existing scripts and content. It is not expected that this goal will be met with full backwards compatibility. However, the specification attempts to achieve this when possible.
The following sections of the Event Model specification define both the specification
for the DOM Event Model and a number of compliant event sets designed for use within the
model. The Event Model consists of the two sections on event propagation and event listener
registration and the Event interface. A DOM consumer can use the hasFeature
of the DOMImplementation interface to determine whether the Event
Model has been implemented by a DOM implementation. The feature string for the
Event Model is "Events". The existence within an implementation of each of the
individual event sets can also be queried using the hasFeature method.
Each event set describes its own feature string in the event set listing.
Event flow is the process through which the an event originates from the DOM implementation
and is passed into the Document Object Model. The methods of event capture and event
bubbling, along with various event listener registration techniques, allow the event
to then be handled in a number of ways. It can be handled locally at the
EventTarget level or centrally from an EventTarget higher in the document tree.
Each event has an EventTarget toward which the event is directed by the DOM implementation. This
EventTarget is specified in the Event's target attribute. When
the event reaches the target, any event
listeners registered on the EventTarget are triggered. Although all EventListeners
on the EventTarget are guaranteed to be triggered by any event which is received by that
EventTarget, no specification is made as to the order
in which they will receive the event with regards to the other EventListeners on the
EventTarget. If neither event
capture or event bubbling are in use for that particular event,
the event flow process will complete after all listeners have been triggered. If event capture
or event bubbling is in use, the event flow will be modified as described in the sections below.
Any exceptions thrown inside an EventListener will not stop propagation of the
event. It will continue processing any additional EventListener in the described manner.
It is expected that actions taken by EventListeners may cause additional events to
fire. Additional events should be handled in a synchronous manner and may cause reentrancy into
the event model.
Event capture is the process by which an EventListener registered on an ancestor
of the event's target can intercept events of a given type before they
are received by the event's target. Capture operates from
the top of the tree, generally the Document, downward, making it the symmetrical opposite of bubbling
which is described below. The chain of EventTargets from the top of the tree
to the event's target is determined before the initial dispatch of the event. If modifications
occur to the tree during event processing, event flow will proceed based on the initial state of the tree.
An EventListener being registered on an EventTarget
may choose to have that EventListener capture events by
specifying the useCapture parameter of the addEventListener
method to be true. Thereafter, when an event of the given type is
dispatched toward a descendant of the capturing object, the event
will trigger any capturing event listeners of the appropriate type
which exist in the direct line between the top of the document and the
event's target. This downward propagation continues until the event's target is
reached. A capturing EventListener will not be triggered by events
dispatched directly to the EventTarget upon which it is registered.
If the capturing EventListener wishes to prevent further
processing of the event from occurring it may call the stopProgagation method of
the Event interface. This will prevent further dispatch of the event, although additional EventListeners registered at
the same hierarchy level will still receive the event. Once an event's
stopPropagation method has been called, further calls to that method have
no additional effect. If no additional capturers exist and stopPropagation
has not been called,
the event triggers the appropriate EventListeners on the target
itself.
Although event capture is similar to the delegation based event
model in which all interested parties register their listeners directly on the target
about which they wish to receive notifications, it is different in two important respects.
First, event capture only allows interception of events which are targeted at descendants
of the capturing EventTarget. It does not allow interception of events
targeted to the capturer's ancestors, its siblings, or its
sibling's descendants. Secondly, event capture is not specified for
a single EventTarget, it is specified for a specific type of event.
Once specified, event capture intercepts all events
of the specified type targeted toward any of the capturer's descendants.
Events which are designated as bubbling will initially proceed with the
same event flow as non-bubbling events. The event is dispatched to its target
EventTarget and any event listeners found there are triggered. Bubbling
events will then trigger any additional event listeners found by following the
EventTarget's parent chain upward, checking for any event listeners
registered on each successive EventTarget. This upward propagation will continue
up to and including the Document. EventListeners registered as
capturers will not be triggered during this phase. The chain of EventTargets from the event
target to the top of the tree is determined before the initial dispatch of the event. If modifications
occur to the tree during event processing, event flow will proceed based on the initial state of the tree.
Any event handler may choose to prevent further event propagation
by calling the stopPropagation method of the Event interface. If
any EventListener calls this method, all additional EventListeners
on the current EventTarget will be triggered but bubbling
will cease at that level. Only one call to stopPropagation is required to
prevent further bubbling.
Some events are specified as cancelable. For these events, the DOM implementation generally has a default action associated with the event. An example of this is a hyperlink in a web browser. When the user clicks on the hyperlink the default action is generally to active that hyperlink. Before processing these events, the implementation must check for event listeners registered to receive the event and dispatch the event to those listeners. These listeners then have the option of canceling the implementation's default action or allowing the default action to proceed. In the case of the hyperlink in the browser, canceling the action would have the result of not activating the hyperlink.
Cancelation is accomplished by calling the Event's
preventDefault method. If one or more EventListeners call
preventDefault during any phase of event flow the default action will
be canceled.
Different implementations will specify their own default actions, if any, associated with each event. The DOM does not attempt to specify these actions.
The EventTarget interface is implemented by all Nodes in
an implementation which supports the DOM Event Model. The interface allows registration
and removal of EventListeners on an EventTarget and dispatch
of events to that EventTarget.
// Introduced in DOM Level 2:
interface EventTarget {
void addEventListener(in DOMString type,
in EventListener listener,
in boolean useCapture);
void removeEventListener(in DOMString type,
in EventListener listener,
in boolean useCapture);
boolean dispatchEvent(in Event evt)
raises(EventException);
};
addEventListenerEventListener is added to an EventTarget while it is
processing an event, it will not be triggered by the current actions but may be
triggered during a later stage of event flow, such as the bubbling phase.
EventListeners are registered on the same
EventTarget with the same parameters the duplicate instances are discarded.
They do not cause the EventListener to be called twice and since they are
discarded they do not need to be removed with the removeEventListener method.
| The event type for which the user is registering | |||
| The | |||
|
| If true, |
dispatchEvent
EventTarget on which dispatchEvent is called.
| Specifies the event type, behavior, and contextual information to be used in processing the event. |
|
The return value of |
removeEventListenerEventListener is removed from an EventTarget while it is
processing an event, it will still be triggered by the current actions but will not
be triggered again during any later stages of event flow, such as bubbling.removeEventListener with arguments which do not identify any
currently registered EventListener on the EventTarget
has no effect.
| Specifies the event type of the | |||
| The | |||
|
| Specifies whether the |
The EventListener interface is the primary method for
handling events. Users implement the EventListener interface
and register their listener on an EventTarget using the
AddEventListener method. The users should also remove their
EventListener from its EventTarget after they
have completed using the listener.
When a Node is copied using the cloneNode method
the EventListeners attached to the source Node are
not attached to the copied Node. If the user wishes the same
EventListeners to be added to the newly created copy the user must add them manually.
// Introduced in DOM Level 2:
interface EventListener {
void handleEvent(in Event evt);
};
handleEvent EventListener interface was registered.
In HTML 4.0, event listeners were specified as attributes of an element. As such,
registration of a second event listener of the same type would replace the
first listener. The DOM Event Model allows registration of multiple event listeners on
a single Node. To achieve this, event listeners are no longer stored as attribute
values.
In order to achieve compatibility with HTML 4.0, implementors may view the setting of
attributes which represent event handlers as the creation and registration of an
EventListener on the Node. The value of useCapture
defaults to false. This EventListener behaves in
the same manner as any other EventListeners which may be registered on the
EventTarget. If the attribute representing the event listener is changed, this may be
viewed as the removal of the previously registered EventListener and the
registration of a new one. No technique is provided to allow HTML 4.0 event listeners
access to the context information defined for each event.
The Event interface is used to provide contextual information about an event
to the handler processing the event. An object which implements the Event interface
is generally passed as the first parameter to an event handler. More specific
context information is passed to event handlers by deriving additional interfaces from
Event which contain information directly relating to the type of event
they accompany. These derived interfaces are also implemented by the object passed to the
event listener.
// Introduced in DOM Level 2:
interface Event {
// PhaseType
const unsigned short CAPTURING_PHASE = 1;
const unsigned short AT_TARGET = 2;
const unsigned short BUBBLING_PHASE = 3;
readonly attribute DOMString type;
readonly attribute EventTarget target;
readonly attribute Node currentNode;
readonly attribute unsigned short eventPhase;
readonly attribute boolean bubbles;
readonly attribute boolean cancelable;
readonly attribute DOMTimeStamp timeStamp;
void stopPropagation();
void preventDefault();
void initEvent(in DOMString eventTypeArg,
in boolean canBubbleArg,
in boolean cancelableArg);
};
An integer indicating which phase of event flow is being processed.
| AT_TARGET | The event is currently being evaluated at the target node. |
| BUBBLING_PHASE | The current event phase is the bubbling phase. |
| CAPTURING_PHASE | The current event phase is the capturing phase. |
bubbles of type boolean, readonly
cancelable of type boolean, readonly
currentNode of type Node, readonlyNode whose
EventListeners are currently being processed. This is particularly
useful during capturing and bubbling.
eventPhase of type unsigned short, readonly
target of type EventTarget, readonlyEventTarget to which the event
was originally dispatched.
timeStamp of type DOMTimeStamp, readonlytimeStamp may be not available for all events. When not
available, a value of 0 will be returned. Examples of epoch time are
the time of the system start or 0:0:0 UTC 1st January 1970.
type of type DOMString, readonly
initEventinitEvent method is used to initialize the value of an Event created through
the DocumentEvent interface. This method may only be called before the Event has
been dispatched via the dispatchEvent method, though it may be called multiple times during that
phase if necessary. If called multiple times the final invocation takes precedence. If called from a
subclass of Event interface only the values specified in the initEvent method are
modified, all other attributes are left unchanged.
| Specifies the event type. This type may be any event type currently defined in this specification or a new event type.. The string must be an XML name. Any new event type must not begin with any upper, lower, or mixed case version of the string "DOM". This prefix is reserved for future DOM event sets. | |||
|
| Specifies whether or not the event can bubble. | ||
|
| Specifies whether or not the event's default action can be prevented. |
preventDefaultpreventDefault method is used
to signify that the event is to be canceled, meaning any default action normally
taken by the implementation as a result of the event will not occur. If, during any stage of event flow,
the preventDefault method is called the event is canceled.
Any default action associated with the event will not occur. Calling this method
for a non-cancelable event has no effect. Once preventDefault has been
called it will remain in effect throughout the remainder of the event's propagation. This
method may be used during any stage of event flow.
stopPropagationstopPropagation method is used prevent further propagation of an event during
event flow. If this method is called by any EventListener the event will cease
propagating through the tree. The event will complete dispatch to all listeners on the current
EventTarget before event flow stops. This method may be used during any stage of
event flow.
Event operations may throw an EventException as specified in
their method descriptions.
// Introduced in DOM Level 2:
exception EventException {
unsigned short code;
};
// EventExceptionCode
const unsigned short UNSPECIFIED_EVENT_TYPE_ERR = 0;
An integer indicating the type of error generated.
| UNSPECIFIED_EVENT_TYPE_ERR |
If the Event's type was not specified by initializing the
event before the method was called. Specification of the Event's type
as null or an empty string will also trigger this
exception.
|
The DocumentEvent interface provides a mechanism by
which the user can create an Event of a type supported by the implementation.
It is expected that the DocumentEvent interface will be implemented
on the same object which implements the Document interface in an
implementation which supports the Event model.
// Introduced in DOM Level 2:
interface DocumentEvent {
Event createEvent(in DOMString eventType)
raises(DOMException);
};
createEvent
| The The |
|
NOT_SUPPORTED_ERR: Raised if the implementation does not support
the type of |
The DOM Level 2 Event Model allows a DOM implementation to support multiple sets of events. The model has been designed to allow addition of new event sets as is required. The DOM will not attempt to define all possible events. For purposes of interoperability, the DOM will define a set of user interface events including lower level device dependent events, a set of UI logical events, and a set of document mutation events.
The User Interface event set is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers.
A DOM consumer can use the hasFeature of the
DOMImplementation interface to determine whether the User Interface
event set has been implemented by a DOM implementation. The feature string
for this event set is "UIEvents". This string is also used with the createEvent
method.
The UIEvent interface provides specific contextual
information associated with User Interface events.
// Introduced in DOM Level 2:
interface UIEvent : Event {
readonly attribute views::AbstractView view;
readonly attribute long detail;
void initUIEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in views::AbstractView viewArg,
in long detailArg);
};
detail of type long, readonlyEvent,
depending on the type of event.
view of type views::AbstractView, readonlyview attribute identifies the
AbstractView from which the event was generated.
initUIEventinitUIEvent method is used to initialize the value of a UIEvent created through
the DocumentEvent interface. This method may only be called before the UIEvent has
been dispatched via the dispatchEvent method, though it may be called multiple times during that
phase if necessary. If called multiple times, the final invocation takes precedence.
| Specifies the event type. | |||
|
| Specifies whether or not the event can bubble. | ||
|
| Specifies whether or not the event's default action can be prevented. | ||
|
| Specifies the | ||
|
| Specifies the |
The different types of such events that can occur are:
The Mouse event set is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers. This event set is specifically designed for use with mouse input devices.
A DOM consumer can use the hasFeature of the
DOMImplementation interface to determine whether the User Interface
event set has been implemented by a DOM implementation. The feature string
for this event set is "MouseEvents". This string is also used with the createEvent
method.
The MouseEvent interface provides specific contextual
information associated with Mouse events.
The detail attribute inherited from UIEvent
indicates the number of times a mouse button has been pressed and
released over the same screen location during a user action. The
attribute value is 1 when the user begins this action and increments by 1
for each full sequence of pressing and releasing. If the user moves the
mouse between the mousedown and mouseup the value will be set to 0,
indicating that no click is occurring.
In the case of nested elements mouse events are always targeted at the most deeply nested element. Ancestors of the targeted element may use bubbling to obtain notification of mouse events which occur within its descendent elements.
// Introduced in DOM Level 2:
interface MouseEvent : UIEvent {
readonly attribute long screenX;
readonly attribute long screenY;
readonly attribute long clientX;
readonly attribute long clientY;
readonly attribute boolean ctrlKey;
readonly attribute boolean shiftKey;
readonly attribute boolean altKey;
readonly attribute boolean metaKey;
readonly attribute unsigned short button;
readonly attribute Node relatedNode;
void initMouseEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in views::AbstractView viewArg,
in long detailArg,
in long screenXArg,
in long screenYArg,
in long clientXArg,
in long clientYArg,
in boolean ctrlKeyArg,
in boolean altKeyArg,
in boolean shiftKeyArg,
in boolean metaKeyArg,
in unsigned short buttonArg,
in Node relatedNodeArg);
};
altKey of type boolean, readonly
button of type unsigned short, readonlybutton is used to indicate which mouse button
changed state. The values for button range from zero to indicate
the left button of the mouse, one to indicate the middle button if present, and
two to indicate the right button. For mice configured for left handed use in which
the button actions are reversed the values are instead read from right to left.
clientX of type long, readonly
clientY of type long, readonly
ctrlKey of type boolean, readonly
metaKey of type boolean, readonly
relatedNode of type Node, readonlyNode which the pointing device exited and with the mouseout event to indicate the
Node which the pointing device entered.
screenX of type long, readonly
screenY of type long, readonly
shiftKey of type boolean, readonly
initMouseEventinitMouseEvent method is used to initialize the value of a MouseEvent created through
the DocumentEvent interface. This method may only be called before the MouseEvent has
been dispatched via the dispatchEvent method, though it may be called multiple times during that
phase if necessary. If called multiple times, the final invocation takes precedence.
| Specifies the event type. | |||
|
| Specifies whether or not the event can bubble. | ||
|
| Specifies whether or not the event's default action can be prevented. | ||
|
| Specifies the | ||
|
| Specifies the | ||
|
| Specifies the | ||
|
| Specifies the | ||
|
| Specifies the | ||
|
| Specifies the | ||
|
| Specifies whether or not control key was depressed during
the | ||
|
| Specifies whether or not alt key was depressed during the
| ||
|
| Specifies whether or not shift key was depressed during the
| ||
|
| Specifies whether or not meta key was depressed during the
| ||
|
| Specifies the | ||
| Specifies the |
The different types of Mouse events that can occur are:
mousedown
mouseup
click
detail attribute incrementing with each repetition.
This event is valid for most elements.Node the pointing device is exiting.Node the pointing device is entering.The DOM Level 2 Event specification does not provide a key event set. An event set designed for use with keyboard input devices will be included in a later version of the DOM specification.
The mutation event set is designed to allow notification of any changes to the structure of a document, including attr and text modifications. It may be noted that none of the mutation events listed are designated as cancelable. This stems from the fact that it is very difficult to make use of existing DOM interfaces which cause document modifications if any change to the document might or might not take place due to cancelation of the related event. Although this is still a desired capability, it was decided that it would be better left until the addition of transactions into the DOM.
Many single modifications of the tree can cause multiple mutation events to be fired. Rather than attempt to specify the ordering of mutation events due to every possible modification of the tree, the ordering of these events is left to the implementation.
A DOM consumer can use the hasFeature of the
DOMImplementation interface to determine whether the mutation
event set has been implemented by a DOM implementation. The feature string
for this event set is "MutationEvents". This string is also used with the createEvent
method.
The MutationEvent interface provides specific contextual
information associated with Mutation events.
// Introduced in DOM Level 2:
interface MutationEvent : Event {
readonly attribute Node relatedNode;
readonly attribute DOMString prevValue;
readonly attribute DOMString newValue;
readonly attribute DOMString attrName;
void initMutationEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in Node relatedNodeArg,
in DOMString prevValueArg,
in DOMString newValueArg,
in DOMString attrNameArg);
};
attrName of type DOMString, readonlyattrName indicates the name of the changed Attr node in a
DOMAttrModified event.
newValue of type DOMString, readonlynewValue indicates the new value of the Attr node in DOMAttrModified
events, and of the CharacterData node in DOMCharDataModified events.
prevValue of type DOMString, readonlyprevValue indicates the previous value of the Attr node in
DOMAttrModified events, and of the CharacterData node in DOMCharDataModified events.
relatedNode of type Node, readonlyrelatedNode is used to identify a secondary node related to a mutation event.
For example, if a mutation event is dispatched to a node indicating that its parent
has changed, the relatedNode is the changed parent. If an event is instead
dispatch to a subtree indicating a node was changed within it, the relatedNode
is the changed node.
initMutationEventinitMutationEvent method is used to initialize the value of a MutationEvent created through
the DocumentEvent interface. This method may only be called before the MutationEvent has
been dispatched via the dispatchEvent method, though it may be called multiple times during that
phase if necessary. If called multiple times, the final invocation takes precedence.
| Specifies the event type. | |||
|
| Specifies whether or not the event can bubble. | ||
|
| Specifies whether or not the event's default action can be prevented. | ||
| Specifies the | |||
| Specifies the | |||
| Specifies the | |||
| Specifies the |
The different types of Mutation events that can occur are:
Attr has been modified on a node. The target of this
event is the Node whose Attr changed. The values of prevValue
and newValue may be the empty string in cases where an attribute has been added or removed.The HTML event set is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers.
A DOM consumer can use the hasFeature of the
DOMImplementation interface to determine whether the HTML
event set has been implemented by a DOM implementation. The feature string
for this event set is "HTMLEvents". This string is also used with the createEvent
method.
The HTML events use the base DOM Event interface to pass contextual information.
The different types of such events that can occur are: