1. Document Object Model Events

Editor:: Tom Pixley, Netscape Communications Corporation

1.1. Overview of the DOM Level 3 Event Model

The DOM Level 3 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 modules of events for user interface control and document mutation notifications, including defined contextual information for each of these event modules.

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 conformant event modules 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 application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "Events" and "3.0" (respectively) to determine whether or not the event module is supported by the implementation. In order to fully support this module, an implementation must also support the "Core" feature defined in the DOM Level 3 Core specification [DOM Level 3 Core]. Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core]. The DOM Level 3 Event module is backward compatible with the DOM Level 2 Events [DOM Level 2 Events] module, i.e. a DOM Level 3 Events implementation who returns true for "Events" with the version number "3.0" must also return true for this feature when the version number is "2.0", "" or, null.

Each event module describes its own feature string in the event module listing.

1.1.1. Terminology

UI events: User interface events. These events are generated by user interaction through an external device (mouse, keyboard, etc.)
UI Logical events: Device independent user interface events such as focus change messages or element triggering notifications.
Mutation events: Events caused by any action which modifies the structure of the document.
Capturing: The process by which an event can be handled by one of the event's target's ancestors before being handled by the event's target.
Bubbling: The process by which an event propagates upward through its ancestors after being handled by the event's target.
Cancelable: A designation for events which indicates that upon handling the event the client may choose to prevent the DOM implementation from processing any default action associated with the event.

1.2. Description of event flow

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. This results in three phases in event flow: the event capture (CAPTURING_PHASE), at the EventTarget (AT_TARGET), and the event bubbling (BUBBLING_PHASE).

1.2.1. Event listeners activation

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.

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.

1.2.2. Event capture

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. Any type of event can be captured.

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.

1.2.3. Event bubbling

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.

1.2.4. Event cancelation

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 activate 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.

1.2.5. EventListener Grouping

EventListener grouping is intended to allow groups of EventListeners to be registered which will each have independent event flow within them which is not affected by changes to event flow in any other group. This may be used to control events separately in multiple views on a document. It may also be used to develop an application which uses events without the problem of possible interference by other applications running within the same document.

The new methods added for EventListener grouping should not interfere with the non-groups methods. For purposes of interoperability between the groups and non-groups methods, the implementation can be assumed to define a default EventGroup. This default EventGroup is implicitly used in the registration of all EventListeners registered via methods which do not specify an EventGroup (addEventListener, removeEventListener).

1.3. Event listener registration

1.3.1. Event registration interfaces

Interface EventTarget (introduced in DOM Level 2)

The EventTarget interface is implemented by all Nodes in an implementation which supports the DOM Event Model. Therefore, this interface can be obtained by using binding-specific casting methods on an instance of the Node interface. The interface allows registration and removal of EventListeners on an EventTarget and dispatch of events to that EventTarget.

IDL Definition

// 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);
  // Introduced in DOM Level 3:
  void               addGroupedEventListener(in DOMString type, 
                                             in EventListener listener, 
                                             in boolean useCapture, 
                                             in EventGroup evtGroup);
  // Introduced in DOM Level 3:
  void               removeGroupedEventListener(in DOMString type, 
                                                in EventListener listener, 
                                                in boolean useCapture, 
                                                in EventGroup evtGroup);
  // Introduced in DOM Level 3:
  boolean            canTrigger(in DOMString type);
  // Introduced in DOM Level 3:
  boolean            isRegisteredHere(in DOMString type);
};

Methods

addEventListener

This method allows the registration of event listeners on the event target. If an EventListener is added to an EventTarget while it is processing an event, the EventListener will not be triggered by the current actions but may be triggered during a later stage of event flow, such as the bubbling phase.
If multiple identical 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.

Parameters

type of type DOMString: The event type for which the user is registering
listener of type EventListener: The listener parameter takes an interface implemented by the user which contains the methods to be called when the event occurs.
useCapture of type boolean: If true, useCapture indicates that the user wishes to initiate capture. After initiating capture, all events of the specified type will be dispatched to the registered EventListener before being dispatched to any EventTargets beneath them in the tree. Events which are bubbling upward through the tree will not trigger an EventListener designated to use capture.

No Return Value

No Exceptions

addGroupedEventListener introduced in DOM Level 3

This method allows the registration of event listeners on the event target in the specified group. If an EventListener is added to an EventTarget while it is processing an event, the EventListener will not be triggered by the current actions, independently of the event groups, but may be triggered during a later stage of event flow, such as the bubbling phase.
If multiple identical 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 removeGroupedEventListener method.

Parameters

type of type DOMString: The event type for which the user is registering
listener of type EventListener: The listener parameter takes an interface implemented by the user which contains the methods to be called when the event occurs.
useCapture of type boolean: If true, useCapture indicates that the user wishes to initiate capture. After initiating capture, all events of the specified type will be dispatched to the registered EventListener before being dispatched to any EventTargets beneath them in the tree. Events which are bubbling upward through the tree will not trigger an EventListener designated to use capture.
evtGroup of type EventGroup: The EventGroup to associate with the EventListener.

No Return Value

No Exceptions

canTrigger introduced in DOM Level 3

This method allows the DOM application to know if an event listener, attached to this EventTarget or one of its ancestors, will be triggered by the specified event type during the dispatch of the event to this event target or one of its descendants.

Parameters

type of type DOMString: The event type for which the EventListener is registered.

Return Value

boolean

true if an event listener will be triggered on the event target with the specified event type, false otherwise.

No Exceptions

dispatchEvent

This method allows the dispatch of events into the implementations event model. Events dispatched in this manner will have the same capturing and bubbling behavior as events dispatched directly by the implementation. The target of the event is the EventTarget on which dispatchEvent is called.

Parameters

evt of type Event: Specifies the event type, behavior, and contextual information to be used in processing the event.

Return Value

boolean

The return value of dispatchEvent indicates whether any of the listeners which handled the event called preventDefault. If preventDefault was called the value is false, else the value is true.

Exceptions

EventException

UNSPECIFIED_EVENT_TYPE_ERR: Raised if the Event's type was not specified by initializing the event before dispatchEvent was called. Specification of the Event's type as null or an empty string will also trigger this exception.

isRegisteredHere introduced in DOM Level 3

This method allows the DOM application to know if this event target contains an event listener registered for the specified event type. This is useful for determining at which nodes within a hierarchy altered handling of specific event types has been introduced, but should not be used to determine whether the specified event type triggers a listener (see canTrigger).

Issue canTriggerOnTarget-useCapture:: do we need a useCapture parameter?
Resolution: No use case for that.

Parameters

type of type DOMString: The event type for which the EventListener is registered.

Return Value

boolean

true if an event listener is registered on this EventTarget for the specified event type, false otherwise.

No Exceptions

removeEventListener

This method allows the removal of event listeners from the event target. If an EventListener is removed from an EventTarget while it is processing an event, it will not be triggered by the current actions. EventListeners can never be invoked after being removed.
Calling removeEventListener with arguments which do not identify any currently registered EventListener on the EventTarget has no effect.

Parameters

type of type DOMString: Specifies the event type of the EventListener being removed.
listener of type EventListener: The EventListener parameter indicates the EventListener to be removed.
useCapture of type boolean: Specifies whether the EventListener being removed was registered as a capturing listener or not. If a listener was registered twice, once with capture and once without, each must be removed separately. Removal of a capturing listener does not affect a non-capturing version of the same listener, and vice versa.

No Return Value

No Exceptions

removeGroupedEventListener introduced in DOM Level 3

This method allows the removal of event listeners from the event target. If an EventListener is removed from an EventTarget while it is processing an event, it will not be triggered by the current actions, independently of the event groups. EventListeners can never be invoked after being removed.
Calling removeGroupedEventListener with arguments which do not identify any currently registered EventListener on the EventTarget has no effect.

Parameters

type of type DOMString: Specifies the event type of the EventListener being removed.
listener of type EventListener: The EventListener parameter indicates the EventListener to be removed.
useCapture of type boolean: Specifies whether the EventListener being removed was registered as a capturing listener or not. If a listener was registered twice, once with capture and once without, each must be removed separately. Removal of a capturing listener does not affect a non-capturing version of the same listener, and vice versa.
evtGroup of type EventGroup: The EventGroup to associate with the EventListener.

No Return Value

No Exceptions

Interface EventGroup (introduced in DOM Level 3)

The EventGroup interface functions primarily as a placeholder for separating the event flows when there are multiple groups of listeners for a DOM tree.

EventListeners can be registered without an EventGroup using the existing EventTarget interface, or with an associated EventGroup using the new EventTargetGroup interface. When an event is dispatched, it is dispatched independently to each EventGroup. In particular, the stopPropagation method of the Event interface only stops propagation within an EventListener's associated EventGroup.

IDL Definition

// Introduced in DOM Level 3:
interface EventGroup {
  boolean            isSameEventGroup(in EventGroup other);
};

Methods

isSameEventGroup

This method checks if the supplied EventGroup is the same as the EventGroup upon which the method is called.

Parameters

other of type EventGroup: The EventGroup with which to check equality.

Return Value

boolean

Returns true if the EventGroups are equal, else returns false.

No Exceptions

Interface EventListener (introduced in DOM Level 2)

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.

When a Node is adopted using the adoptNode method the EventListeners attached to the source Node stay attached to the adopted Node.

IDL Definition

// Introduced in DOM Level 2:
interface EventListener {
  void               handleEvent(in Event evt);
};

Methods

handleEvent

This method is called whenever an event occurs of the type for which the EventListener interface was registered.

Parameters

evt of type Event: The Event contains contextual information about the event. It also contains the stopPropagation and preventDefault methods which are used in determining the event's flow and default action.

No Return Value

No Exceptions

1.3.2. Interaction with HTML 4.0 event listeners

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 EventTarget. 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 EventTarget. 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.

1.4. Basic interfaces

Interface Event (introduced in DOM Level 2)

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.

IDL Definition

// 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 EventTarget     currentTarget;
  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);
};

Definition group PhaseType

An integer indicating which phase of event flow is being processed.

Defined Constants

AT_TARGET: The event is currently being evaluated at the target EventTarget.
BUBBLING_PHASE: The current event phase is the bubbling phase.
CAPTURING_PHASE: The current event phase is the capturing phase.

Attributes

bubbles of type boolean, readonly

Used to indicate whether or not an event is a bubbling event. If the event can bubble the value is true, else the value is false.

cancelable of type boolean, readonly

Used to indicate whether or not an event can have its default action prevented. If the default action can be prevented the value is true, else the value is false.

currentTarget of type EventTarget, readonly

Used to indicate the EventTarget whose EventListeners are currently being processed. This is particularly useful during capturing and bubbling.

eventPhase of type unsigned short, readonly

Used to indicate which phase of event flow is currently being evaluated.

target of type EventTarget, readonly

Used to indicate the EventTarget to which the event was originally dispatched.

timeStamp of type DOMTimeStamp, readonly

Used to specify the time (in milliseconds relative to the epoch) at which the event was created. Due to the fact that some systems may not provide this information the value of timeStamp 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

The name of the event (case-insensitive). The name must be an XML name. On retrieval, the name of the event is in lowercase.

Issue lowercase-1:: check implementation for lowercase.
Issue naming-1:: XML events might (will?) use {namespaceURI,localName} to indicate the type of events in the future. What should we do about it?

Methods

initEvent

The initEvent 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.

Parameters

eventTypeArg of type DOMString: 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. It is also strongly recommended that third parties adding their own events use their own prefix to avoid confusion and lessen the probability of conflicts with other new events.
canBubbleArg of type boolean: Specifies whether or not the event can bubble.
cancelableArg of type boolean: Specifies whether or not the event's default action can be prevented.

No Return Value

No Exceptions

preventDefault

If an event is cancelable, the preventDefault 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.

No Parameters

No Return Value

No Exceptions

stopPropagation

The stopPropagation method is used to prevent further propagation of an event in the current group during event flow (see also EventListener Grouping). If this method is called by any EventListener the event will cease propagating in the current group 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.

No Parameters

No Return Value

No Exceptions

Exception EventException introduced in DOM Level 2

Event operations may throw an EventException as specified in their method descriptions.

IDL Definition

// Introduced in DOM Level 2:
exception EventException {
  unsigned short   code;
};
// EventExceptionCode
const unsigned short      UNSPECIFIED_EVENT_TYPE_ERR     = 0;

Definition group EventExceptionCode

An integer indicating the type of error generated.

Defined Constants

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.

1.4.1. Event creation

Interface DocumentEvent (introduced in DOM Level 2)

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.

IDL Definition

// Introduced in DOM Level 2:
interface DocumentEvent {
  Event              createEvent(in DOMString eventType)
                                        raises(DOMException);
  EventGroup         createEventGroup();
};

Methods

createEvent

Parameters

eventType of type DOMString: The eventType parameter specifies the type of Event interface to be created. If the Event interface specified is supported by the implementation this method will return a new Event of the interface type requested. If the Event is to be dispatched via the dispatchEvent method the appropriate event init method must be called after creation in order to initialize the Event's values. As an example, a user wishing to synthesize some kind of UIEvent would call createEvent with the parameter "UIEvents". The initUIEvent method could then be called on the newly created UIEvent to set the specific type of UIEvent to be dispatched and set its context information.
The createEvent method is used in creating Events when it is either inconvenient or unnecessary for the user to create an Event themselves. In cases where the implementation provided Event is insufficient, users may supply their own Event implementations for use with the dispatchEvent method. However, the DOM implementation needs access to the attributes currentTarget and eventPhase of the Event interface to propagate appropriately the event in the DOM tree. Therefore users Event implementation might need to support the CustomEvent for that effect.

Return Value

Event

The newly created Event

Exceptions

DOMException

NOT_SUPPORTED_ERR: Raised if the implementation does not support the type of Event interface requested

createEventGroup

This method creates a new EventGroup for use in the addGroupedEventListener and removeGroupedEventListener methods of the EventTarget interface.

Return Value

EventGroup

The newly created EventGroup.

No Parameters

No Exceptions

Interface CustomEvent (introduced in DOM Level 3)

The CustomEvent interface provides user defined events. It is intented to be used by the DOM implementation to access the underlying while propagating the event in the tree. Both methods should be call before invoking each event listener on the current target.

IDL Definition

// Introduced in DOM Level 3:
interface CustomEvent : Event {
  void               setCurrentTarget(in Node target);
  void               setEventPhase(in unsigned short phase);
};

Methods

setCurrentTarget

The setCurrentTarget method is used by the DOM implementation to change the value of a currentTarget attribute on the Event interface.

Parameters

target of type Node: Specifies the currentTarget attribute on the Event interface.

No Return Value

No Exceptions

setEventPhase

The setEventPhase method is used by the DOM implementation to change the value of a eventPhase attribute on the Event interface.

Parameters

phase of type unsigned short: Specifies the eventPahse attribute on the Event interface.

No Return Value

No Exceptions

1.5. Event module definitions

The DOM Level 2 Event Model allows a DOM implementation to support multiple modules of events. The model has been designed to allow addition of new event modules as is required. The DOM will not attempt to define all possible events. For purposes of interoperability, the DOM will define a module of user interface events including lower level device dependent events, a module of UI logical events, and a module of document mutation events. Any new event types defined by third parties must not begin with any upper, lower, or mixed case version of the string "DOM". This prefix is reserved for future DOM event modules. It is also strongly recommended that third parties adding their own events use their own prefix to avoid confusion and lessen the probability of conflicts with other new events.

1.5.1. User Interface event types

The User Interface event module is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers.

A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "UIEvents" and "3.0" (respectively) to determine whether or not the User Interface event module is supported by the implementation. In order to fully support this module, an implementation must also support the "Events" feature defined in this specification and the "Views" feature defined in the DOM Level 2 Views specification [DOM Level 2 Views]. Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core]. The DOM Level 3 User Interface Events module is backward compatible with the DOM Level 2 User Interface Events [DOM Level 2 Events] module, i.e. a DOM Level 3 User Interface Events implementation who returns true for "UIEvents" with the version number "3.0" must also return true for this feature when the version number is "2.0", "" or, null.

Note: To create an instance of the UIEvent interface, use the feature string "UIEvents" as the value of the input parameter used with the createEvent method of the DocumentEvent interface.

Interface UIEvent (introduced in DOM Level 2)

The UIEvent interface provides specific contextual information associated with User Interface events.

IDL Definition

// 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);
};

Attributes

detail of type long, readonly: Specifies some detail information about the Event, depending on the type of event.
view of type views::AbstractView, readonly: The view attribute identifies the AbstractView from which the event was generated.

Methods

initUIEvent

The initUIEvent 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.

Parameters

typeArg of type DOMString: Specifies the event type.
canBubbleArg of type boolean: Specifies whether or not the event can bubble.
cancelableArg of type boolean: Specifies whether or not the event's default action can be prevented.
viewArg of type views::AbstractView: Specifies the Event's AbstractView.
detailArg of type long: Specifies the Event's detail.

No Return Value

No Exceptions

The different types of such events that can occur are:

DOMFocusIn

The DOMFocusIn event occurs when an EventTarget receives focus, for instance via a pointing device being moved onto an element or by tabbing navigation to the element. Unlike the HTML event focus, DOMFocusIn can be applied to any focusable EventTarget, not just FORM controls.

Bubbles: Yes
Cancelable: No
Context Info: None

DOMFocusOut

The DOMFocusOut event occurs when a EventTarget loses focus, for instance via a pointing device being moved out of an element or by tabbing navigation out of the element. Unlike the HTML event blur, DOMFocusOut can be applied to any focusable EventTarget, not just FORM controls.

Bubbles: Yes
Cancelable: No
Context Info: None

DOMActivate

The activate event occurs when an element is activated, for instance, thru a mouse click or a keypress. A numerical argument is provided to give an indication of the type of activation that occurs: 1 for a simple activation (e.g. a simple click or Enter), 2 for hyperactivation (for instance a double click or Shift Enter).

Bubbles: Yes
Cancelable: Yes
Context Info: detail (the numerical value)

1.5.2. Mouse event types

The Mouse event module is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers. This event module is specifically designed for use with mouse input devices.

A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "MouseEvents" and "3.0" (respectively) to determine whether or not the Mouse event module is supported by the implementation. In order to fully support this module, an implementation must also support the "UIEvents" feature defined in this specification. Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core]. The DOM Level 3 Mouse Events module is backward compatible with the DOM Level 2 Mouse Events [DOM Level 2 Events] module, i.e. a DOM Level 3 Mouse Events implementation who returns true for "MouseEvents" with the version number "3.0" must also return true for this feature when the version number is "2.0", "" or, null.

Note: To create an instance of the MouseEvent interface, use the feature string "MouseEvents" as the value of the input parameter used with the createEvent method of the DocumentEvent interface.

Interface MouseEvent (introduced in DOM Level 2)

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.

IDL Definition

// 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 EventTarget     relatedTarget;
  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 EventTarget relatedTargetArg);
};

Attributes

altKey of type boolean, readonly: Used to indicate whether the 'alt' key was depressed during the firing of the event. On some platforms this key may map to an alternative key name.
button of type unsigned short, readonly: During mouse events caused by the depression or release of a mouse button, button 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: The horizontal coordinate at which the event occurred relative to the DOM implementation's client area.
clientY of type long, readonly: The vertical coordinate at which the event occurred relative to the DOM implementation's client area.
ctrlKey of type boolean, readonly: Used to indicate whether the 'ctrl' key was depressed during the firing of the event.
metaKey of type boolean, readonly: Used to indicate whether the 'meta' key was depressed during the firing of the event. On some platforms this key may map to an alternative key name.
relatedTarget of type EventTarget, readonly: Used to identify a secondary EventTarget related to a UI event. Currently this attribute is used with the mouseover event to indicate the EventTarget which the pointing device exited and with the mouseout event to indicate the EventTarget which the pointing device entered.
screenX of type long, readonly: The horizontal coordinate at which the event occurred relative to the origin of the screen coordinate system.
screenY of type long, readonly: The vertical coordinate at which the event occurred relative to the origin of the screen coordinate system.
shiftKey of type boolean, readonly: Used to indicate whether the 'shift' key was depressed during the firing of the event.

Methods

initMouseEvent

The initMouseEvent 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.

Parameters

typeArg of type DOMString: Specifies the event type.
canBubbleArg of type boolean: Specifies whether or not the event can bubble.
cancelableArg of type boolean: Specifies whether or not the event's default action can be prevented.
viewArg of type views::AbstractView: Specifies the Event's AbstractView.
detailArg of type long: Specifies the Event's mouse click count.
screenXArg of type long: Specifies the Event's screen x coordinate
screenYArg of type long: Specifies the Event's screen y coordinate
clientXArg of type long: Specifies the Event's client x coordinate
clientYArg of type long: Specifies the Event's client y coordinate
ctrlKeyArg of type boolean: Specifies whether or not control key was depressed during the Event.
altKeyArg of type boolean: Specifies whether or not alt key was depressed during the Event.
shiftKeyArg of type boolean: Specifies whether or not shift key was depressed during the Event.
metaKeyArg of type boolean: Specifies whether or not meta key was depressed during the Event.
buttonArg of type unsigned short: Specifies the Event's mouse button.
relatedTargetArg of type EventTarget: Specifies the Event's related EventTarget.

No Return Value

No Exceptions

The different types of Mouse events that can occur are:

click

The click event occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is:

    mousedown
    mouseup
    click

If multiple clicks occur at the same screen location, the sequence repeats with the detail attribute incrementing with each repetition. This event is valid for most elements.

Bubbles: Yes
Cancelable: Yes
Context Info: screenX, screenY, clientX, clientY, altKey, ctrlKey, shiftKey, metaKey, button, detail, view

mousedown

The mousedown event occurs when the pointing device button is pressed over an element. This event is valid for most elements.

Bubbles: Yes
Cancelable: Yes
Context Info: screenX, screenY, clientX, clientY, altKey, ctrlKey, shiftKey, metaKey, button, detail, view

mouseup

The mouseup event occurs when the pointing device button is released over an element. This event is valid for most elements.

Bubbles: Yes
Cancelable: Yes
Context Info: screenX, screenY, clientX, clientY, altKey, ctrlKey, shiftKey, metaKey, button, detail, view

mouseover

The mouseover event occurs when the pointing device is moved onto an element. This event is valid for most elements.

Bubbles: Yes
Cancelable: Yes
Context Info: view, screenX, screenY, clientX, clientY, altKey, ctrlKey, shiftKey, metaKey, relatedTarget indicates the EventTarget the pointing device is exiting.

mousemove

The mousemove event occurs when the pointing device is moved while it is over an element. This event is valid for most elements.

Bubbles: Yes
Cancelable: No
Context Info: view, screenX, screenY, clientX, clientY, altKey, ctrlKey, shiftKey, metaKey

mouseout

The mouseout event occurs when the pointing device is moved away from an element. This event is valid for most elements..

Bubbles: Yes
Cancelable: Yes
Context Info: view, screenX, screenY, clientX, clientY, altKey, ctrlKey, shiftKey, metaKey, relatedTarget indicates the EventTarget the pointing device is entering.

1.5.3. Text events

A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "TextEvents" and "3.0" (respectively) to determine whether or not the Text event module is supported by the implementation. In order to fully support this module, an implementation must also support the "UIEvents" feature defined in this specification. Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core].

Note: To create an instance of the TextEvent interface, use the feature string "TextEvents" as the value of the input parameter used with the createEvent method of the DocumentEvent interface.

Interface TextEvent (introduced in DOM Level 3)

The TextEvent interface provides specific contextual information associated with Text Events.

IDL Definition

// Introduced in DOM Level 3:
interface TextEvent : UIEvent {

  // VirtualKeyCode
  const unsigned long       DOM_VK_UNDEFINED               = 0x0;
  const unsigned long       DOM_VK_RIGHT_ALT               = 0x01;
  const unsigned long       DOM_VK_LEFT_ALT                = 0x02;
  const unsigned long       DOM_VK_LEFT_CONTROL            = 0x03;
  const unsigned long       DOM_VK_RIGHT_CONTROL           = 0x04;
  const unsigned long       DOM_VK_LEFT_SHIFT              = 0x05;
  const unsigned long       DOM_VK_RIGHT_SHIFT             = 0x06;
  const unsigned long       DOM_VK_LEFT_META               = 0x07;
  const unsigned long       DOM_VK_RIGHT_META              = 0x08;
  const unsigned long       DOM_VK_CAPS_LOCK               = 0x09;
  const unsigned long       DOM_VK_DELETE                  = 0x0A;
  const unsigned long       DOM_VK_END                     = 0x0B;
  const unsigned long       DOM_VK_ENTER                   = 0x0C;
  const unsigned long       DOM_VK_ESCAPE                  = 0x0D;
  const unsigned long       DOM_VK_HOME                    = 0x0E;
  const unsigned long       DOM_VK_INSERT                  = 0x0F;
  const unsigned long       DOM_VK_NUM_LOCK                = 0x10;
  const unsigned long       DOM_VK_PAUSE                   = 0x11;
  const unsigned long       DOM_VK_PRINTSCREEN             = 0x12;
  const unsigned long       DOM_VK_SCROLL_LOCK             = 0x13;
  const unsigned long       DOM_VK_LEFT                    = 0x14;
  const unsigned long       DOM_VK_RIGHT                   = 0x15;
  const unsigned long       DOM_VK_UP                      = 0x16;
  const unsigned long       DOM_VK_DOWN                    = 0x17;
  const unsigned long       DOM_VK_PAGE_DOWN               = 0x18;
  const unsigned long       DOM_VK_PAGE_UP                 = 0x19;
  const unsigned long       DOM_VK_F1                      = 0x1A;
  const unsigned long       DOM_VK_F2                      = 0x1B;
  const unsigned long       DOM_VK_F3                      = 0x1C;
  const unsigned long       DOM_VK_F4                      = 0x1D;
  const unsigned long       DOM_VK_F5                      = 0x1E;
  const unsigned long       DOM_VK_F6                      = 0x1F;
  const unsigned long       DOM_VK_F7                      = 0x20;
  const unsigned long       DOM_VK_F8                      = 0x21;
  const unsigned long       DOM_VK_F9                      = 0x22;
  const unsigned long       DOM_VK_F10                     = 0x23;
  const unsigned long       DOM_VK_F11                     = 0x24;
  const unsigned long       DOM_VK_F12                     = 0x25;
  const unsigned long       DOM_VK_F13                     = 0x26;
  const unsigned long       DOM_VK_F14                     = 0x27;
  const unsigned long       DOM_VK_F15                     = 0x28;
  const unsigned long       DOM_VK_F16                     = 0x29;
  const unsigned long       DOM_VK_F17                     = 0x2A;
  const unsigned long       DOM_VK_F18                     = 0x2B;
  const unsigned long       DOM_VK_F19                     = 0x2C;
  const unsigned long       DOM_VK_F20                     = 0x2D;
  const unsigned long       DOM_VK_F21                     = 0x2E;
  const unsigned long       DOM_VK_F22                     = 0x2F;
  const unsigned long       DOM_VK_F23                     = 0x30;
  const unsigned long       DOM_VK_F24                     = 0x31;

           attribute DOMString       outputString;
           attribute unsigned long   keyVal;
           attribute unsigned long   virtKeyVal;
           attribute boolean         visibleOutputGenerated;
           attribute boolean         numPad;
  boolean            checkModifier(in unsigned long modifier);
  void               initTextEvent(in DOMString typeArg, 
                                   in boolean canBubbleArg, 
                                   in boolean cancelableArg, 
                                   in views::AbstractView viewArg, 
                                   in long detailArg, 
                                   in DOMString outputStringArg, 
                                   in unsigned long keyValArg, 
                                   in unsigned long virtKeyValArg, 
                                   in boolean visibleOutputGeneratedArg, 
                                   in boolean numPadArg);
  void               initModifier(in unsigned long modifier, 
                                  in boolean value);
};

Definition group VirtualKeyCode

An integer indicating which key was pressed.

Defined Constants

DOM_VK_CAPS_LOCK
DOM_VK_DELETE
DOM_VK_DOWN
DOM_VK_END
DOM_VK_ENTER
DOM_VK_ESCAPE
DOM_VK_F1: Constant for the F1 function key.
DOM_VK_F10: Constant for the F10 function key.
DOM_VK_F11: Constant for the F11 function key.
DOM_VK_F12: Constant for the F12 function key.
DOM_VK_F13: Constant for the F13 function key.
DOM_VK_F14: Constant for the F14 function key.
DOM_VK_F15: Constant for the F15 function key.
DOM_VK_F16: Constant for the F16 function key.
DOM_VK_F17: Constant for the F17 function key.
DOM_VK_F18: Constant for the F18 function key.
DOM_VK_F19: Constant for the F19 function key.
DOM_VK_F2: Constant for the F2 function key.
DOM_VK_F20: Constant for the F20 function key.
DOM_VK_F21: Constant for the F21 function key.
DOM_VK_F22: Constant for the F22 function key.
DOM_VK_F23: Constant for the F23 function key.
DOM_VK_F24: Constant for the F24 function key.
DOM_VK_F3: Constant for the F3 function key.
DOM_VK_F4: Constant for the F4 function key.
DOM_VK_F5: Constant for the F5 function key.
DOM_VK_F6: Constant for the F6 function key.
DOM_VK_F7: Constant for the F7 function key.
DOM_VK_F8: Constant for the F8 function key.
DOM_VK_F9: Constant for the F9 function key.
DOM_VK_HOME
DOM_VK_INSERT
DOM_VK_LEFT
DOM_VK_LEFT_ALT: This key is a modifier key
DOM_VK_LEFT_CONTROL: This key is a modifier key
DOM_VK_LEFT_META: This key is a modifier key
DOM_VK_LEFT_SHIFT: This key is a modifier key
DOM_VK_NUM_LOCK
DOM_VK_PAGE_DOWN
DOM_VK_PAGE_UP
DOM_VK_PAUSE
DOM_VK_PRINTSCREEN
DOM_VK_RIGHT
DOM_VK_RIGHT_ALT: This key is a modifier key
DOM_VK_RIGHT_CONTROL: This key is a modifier key
DOM_VK_RIGHT_META: This key is a modifier key
DOM_VK_RIGHT_SHIFT: This key is a modifier key
DOM_VK_SCROLL_LOCK
DOM_VK_UNDEFINED: Used for key events which do not have a virtual key code available.
DOM_VK_UP

Attributes

keyVal of type unsigned long: The value of keyVal holds the value of the Unicode character associated with the depressed key. If the key has no Unicode representation or no Unicode character is available the value is 0..
numPad of type boolean: The numPad attribute indicates whether or not the key event was generated on the number pad section of the keyboard. If the number pad was used to generate the key event the value is true, otherwise the value is false.
outputString of type DOMString: outputString holds the value of the output generated by the key event. This may be a single Unicode character or it may be a string. It may also be null in the case where no output was generated by the key event.
virtKeyVal of type unsigned long: When the key associated with a key event is not representable via a Unicode character virtKeyVal holds the virtual key code associated with the depressed key. If the key has a Unicode representation or no virtual code is available the value is DOM_VK_UNDEFINED.
visibleOutputGenerated of type boolean: The visibleOutputGenerated attribute indicates whether the key event will normally cause visible output. If the key event does not generate any visible output, such as the use of a function key or the combination of certain modifier keys used in conjunction with another key, then the value will be false. If visible output is normally generated by the key event then the value will be true.
The value of visibleOutputGenerated does not guarantee the creation of a character. If a key event causing visible output is cancelable it may be prevented from causing visible output. This attribute is intended primarily to differentiate between keys events which may or may not produce visible output depending on the system state.

Methods

checkModifier

The checkModifier method is used to check the status of a single modifier key associated with a TextEvent. The identifier of the modifier in question is passed into the checkModifier function. If the modifier is triggered it will return true. If not, it will return false.
The list of keys below represents the allowable modifier paramaters for this method.

DOM_VK_LEFT_ALT
DOM_VK_RIGHT_ALT
DOM_VK_LEFT_CONTROL
DOM_VK_RIGHT_CONTROL
DOM_VK_LEFT_SHIFT
DOM_VK_RIGHT_SHIFT
DOM_VK_META

Parameters

modifier of type unsigned long: The modifier which the user wishes to query.

Return Value

boolean

The status of the modifier represented as a boolean.

No Exceptions

initModifier

The initModifier method is used to initialize the values of any modifiers associated with a TextEvent created through the DocumentEvent interface. This method may only be called before the TextEvent has been dispatched via the dispatchEvent method, though it may be called multiple times during that phase if necessary. If called multiple times with the same modifier property the final invocation takes precedence. Unless explicitly give a value of true, all modifiers have a value of false. This method has no effect if called after the event has been dispatched.
The list of keys below represents the allowable modifier paramaters for this method.

DOM_VK_LEFT_ALT
DOM_VK_RIGHT_ALT
DOM_VK_LEFT_CONTROL
DOM_VK_RIGHT_CONTROL
DOM_VK_LEFT_SHIFT
DOM_VK_RIGHT_SHIFT
DOM_VK_META

Parameters

modifier of type unsigned long: The modifier which the user wishes to initialize
value of type boolean: The new value of the modifier.

No Return Value

No Exceptions

initTextEvent

The initTextEvent method is used to initialize the value of a TextEvent created through the DocumentEvent interface. This method may only be called before the TextEvent 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. This method has no effect if called after the event has been dispatched.

Parameters

typeArg of type DOMString: Specifies the event type.
canBubbleArg of type boolean: Specifies whether or not the event can bubble.
cancelableArg of type boolean: Specifies whether or not the event's default action can be prevent.
viewArg of type views::AbstractView: Specifies the TextEvent's AbstractView.
detailArg of type long: Specifies the number of repeated keypresses, if available.
outputStringArg of type DOMString: Specifies the TextEvent's outputString attribute
keyValArg of type unsigned long: Specifies the TextEvent's keyValattribute
virtKeyValArg of type unsigned long: Specifies the TextEvent's virtKeyValattribute
visibleOutputGeneratedArg of type boolean: Specifies the TextEvent's visibleOutputGeneratedattribute
numPadArg of type boolean: Specifies the TextEvent's numPadattribute

No Return Value

No Exceptions

There are two major groups of key events. The first contains the textInput event. The textInput event indicates that text information has been entered, either in the form of printable characters or non-printable text information such as modifier keys. textInput events are not necessarily accompanied by the events of the second major groups of key events, keydown and keyup.

textInput

The textInput event indicates that text information has been entered. The text information entered can originate from a variety of sources. It could, for example, be a character resulting from a keypress. It could also be a string resulting from an input method.
The detail attribute inherited from UIEvent is used to indicated the number of keypresses which have occurred during key repetition. If this information is not available this value should be 0.

Bubbles: Yes
Cancelable: Yes
Context Info: view, detail, visibleOutputGenerated, outputString, keyVal, virtKeyVal, numPad.

The keydown and keyup events comprise the second group of key events. These events are fired to indicate the physical motion of the keys on the character generation device. Depending on the input system being used, textEvent events may or may not be generated for each pair of keydown and keyup events.

keydown

The keydown event occurs when a key is pressed down.

Bubbles: Yes
Cancelable: Yes
Context Info: view, keyVal, virtKeyVal, numPad.

keyup

The keyup event occurs when a key is released.

Bubbles: Yes
Cancelable: Yes
Context Info: view, keyVal, virtKeyVal, numPad.

1.5.4. Mutation event types

The mutation event module 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 application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "MutationEvents" and "3.0" (respectively) to determine whether or not the Mutation event module is supported by the implementation. In order to fully support this module, an implementation must also support the "Events" feature defined in this specification. Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core]. The DOM Level 3 Mutation Events module is backward compatible with the DOM Level 2 Mutation Events [DOM Level 2 Events] module, i.e. a DOM Level 3 Mutation Events implementation who returns true for "MutationEvents" with the version number "3.0" must also return true for this feature when the version number is "2.0", "" or, null.

Note: To create an instance of the MutationEvent interface, use the feature string "MutationEvents" as the value of the input parameter used with the createEvent method of the DocumentEvent interface.

Interface MutationEvent (introduced in DOM Level 2)

The MutationEvent interface provides specific contextual information associated with Mutation events.

IDL Definition

// Introduced in DOM Level 2:
interface MutationEvent : Event {

  // attrChangeType
  const unsigned short      MODIFICATION                   = 1;
  const unsigned short      ADDITION                       = 2;
  const unsigned short      REMOVAL                        = 3;

  readonly attribute Node            relatedNode;
  readonly attribute DOMString       prevValue;
  readonly attribute DOMString       newValue;
  readonly attribute DOMString       attrName;
  readonly attribute unsigned short  attrChange;
  void               initMutationEvent(in DOMString typeArg, 
                                       in boolean canBubbleArg, 
                                       in boolean cancelableArg, 
                                       in Node relatedNodeArg, 
                                       in DOMString prevValueArg, 
                                       in DOMString newValueArg, 
                                       in DOMString attrNameArg, 
                                       in unsigned short attrChangeArg);
};

Definition group attrChangeType

An integer indicating in which way the Attr was changed.

Defined Constants

ADDITION: The Attr was just added.
MODIFICATION: The Attr was modified in place.
REMOVAL: The Attr was just removed.

Attributes

attrChange of type unsigned short, readonly: attrChange indicates the type of change which triggered the DOMAttrModified event. The values can be MODIFICATION, ADDITION, or REMOVAL.
attrName of type DOMString, readonly: attrName indicates the name of the changed Attr node in a DOMAttrModified event.
newValue of type DOMString, readonly: newValue indicates the new value of the Attr node in DOMAttrModified events, and of the CharacterData node in DOMCharacterDataModified events.
prevValue of type DOMString, readonly: prevValue indicates the previous value of the Attr node in DOMAttrModified events, and of the CharacterData node in DOMCharacterDataModified events.
relatedNode of type Node, readonly: relatedNode 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 dispatched to a subtree indicating a node was changed within it, the relatedNode is the changed node. In the case of the DOMAttrModified event it indicates the Attr node which was modified, added, or removed.

Methods

initMutationEvent

The initMutationEvent 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.

Parameters

typeArg of type DOMString: Specifies the event type.
canBubbleArg of type boolean: Specifies whether or not the event can bubble.
cancelableArg of type boolean: Specifies whether or not the event's default action can be prevented.
relatedNodeArg of type Node: Specifies the Event's related Node.
prevValueArg of type DOMString: Specifies the Event's prevValue attribute. This value may be null.
newValueArg of type DOMString: Specifies the Event's newValue attribute. This value may be null.
attrNameArg of type DOMString: Specifies the Event's attrName attribute. This value may be null.
attrChangeArg of type unsigned short: Specifies the Event's attrChange attribute

No Return Value

No Exceptions

The different types of Mutation events that can occur are:

DOMSubtreeModified

This is a general event for notification of all changes to the document. It can be used instead of the more specific events listed below. It may be fired after a single modification to the document or, at the implementation's discretion, after multiple changes have occurred. The latter use should generally be used to accomodate multiple changes which occur either simultaneously or in rapid succession. The target of this event is the lowest common parent of the changes which have taken place. This event is dispatched after any other events caused by the mutation have fired.

Bubbles: Yes
Cancelable: No
Context Info: None

DOMNodeInserted

Fired when a node has been added as a child of another node. This event is dispatched after the insertion has taken place. The target of this event is the node being inserted.

Bubbles: Yes
Cancelable: No
Context Info: relatedNode holds the parent node

DOMNodeRemoved

Fired when a node is being removed from its parent node. This event is dispatched before the node is removed from the tree. The target of this event is the node being removed.

Bubbles: Yes
Cancelable: No
Context Info: relatedNode holds the parent node

DOMNodeRemovedFromDocument

Fired when a node is being removed from a document, either through direct removal of the Node or removal of a subtree in which it is contained. This event is dispatched before the removal takes place. The target of this event is the Node being removed. If the Node is being directly removed the DOMNodeRemoved event will fire before the DOMNodeRemovedFromDocument event.

Bubbles: No
Cancelable: No
Context Info: None

DOMNodeInsertedIntoDocument

Fired when a node is being inserted into a document, either through direct insertion of the Node or insertion of a subtree in which it is contained. This event is dispatched after the insertion has taken place. The target of this event is the node being inserted. If the Node is being directly inserted the DOMNodeInserted event will fire before the DOMNodeInsertedIntoDocument event.

Bubbles: No
Cancelable: No
Context Info: None

DOMAttrModified

Fired after an Attr has been modified on a node. The target of this event is the Node whose Attr changed. The value of attrChange indicates whether the Attr was modified, added, or removed. The value of relatedNode indicates the Attr node whose value has been affected. It is expected that string based replacement of an Attr value will be viewed as a modification of the Attr since its identity does not change. Subsequently replacement of the Attr node with a different Attr node is viewed as the removal of the first Attr node and the addition of the second.

Bubbles: Yes
Cancelable: No
Context Info: attrName, attrChange, prevValue, newValue, relatedNode

DOMCharacterDataModified

Fired after CharacterData within a node has been modified but the node itself has not been inserted or deleted. This event is also triggered by modifications to PI elements. The target of this event is the CharacterData node.

Bubbles: Yes
Cancelable: No
Context Info: prevValue, newValue

1.5.5. HTML event types

The HTML event module is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers.

A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "HTMLEvents" and "3.0" (respectively) to determine whether or not the HTML event module is supported by the implementation. In order to fully support this module, an implementation must also support the "Events" feature defined in this specification. Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core]. The DOM Level 3 HTML Events module is backward compatible with the DOM Level 2 HTML Events [DOM Level 2 Events] module, i.e. a DOM Level 3 HTML Events implementation who returns true for "HTMLEvents" with the version number "3.0" must also return true for this feature when the version number is "2.0", "" or, null.

Note: To create an instance of the Event interface for the HTML event module, use the feature string "HTMLEvents" as the value of the input parameter used with the createEvent method of the DocumentEvent interface.

The HTML events use the base DOM Event interface to pass contextual information.

The different types of such events that can occur are:

load

The load event occurs when the DOM implementation finishes loading all content within the BODY element, all frames within a FRAMESET, or an OBJECT element.

Bubbles: No
Cancelable: No
Context Info: None

unload

The unload event occurs when the DOM implementation removes a document from a window or frame. This event is valid for BODY and FRAMESET elements.

Bubbles: No
Cancelable: No
Context Info: None

abort

The abort event occurs when page loading is stopped before an image has been allowed to completely load. This event applies to OBJECT elements.

Bubbles: Yes
Cancelable: No
Context Info: None

error

The error event occurs when an image does not load properly or when an error occurs during script execution. This event is valid for OBJECT elements, BODY elements, and FRAMESET element.

Bubbles: Yes
Cancelable: No
Context Info: None

select

The select event occurs when a user selects some text in a text field. This event is valid for INPUT and TEXTAREA elements.

Bubbles: Yes
Cancelable: No
Context Info: None

change

The change event occurs when a control loses the input focus and its value has been modified since gaining focus. This event is valid for INPUT, SELECT, and TEXTAREA. element.

Bubbles: Yes
Cancelable: No
Context Info: None

submit

The submit event occurs when a form is submitted. This event only applies to the FORM element.

Bubbles: Yes
Cancelable: Yes
Context Info: None

reset

The reset event occurs when a form is reset. This event only applies to the FORM element.

Bubbles: Yes
Cancelable: No
Context Info: None

focus

The focus event occurs when an element receives focus either via a pointing device or by tabbing navigation. This event is valid for the following elements: A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

Bubbles: No
Cancelable: No
Context Info: None

blur

The blur event occurs when an element loses focus either via the pointing device or by tabbing navigation. This event is valid for the following elements: A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

Bubbles: No
Cancelable: No
Context Info: None

resize

The resize event occurs when a document view is resized.

Bubbles: Yes
Cancelable: No
Context Info: None

scroll

The scroll event occurs when a document view is scrolled.

Bubbles: Yes
Cancelable: No
Context Info: None

1.6. Issues

Issue getModifier:: Why is modifier state exposed through a method rather than an attribute?
Resolution: The modifier keys are not currently representable as bit flags. Setting them individually would therefore require an attribute for each. Rather than bloat the api, especially given the addition of left and right modifier keys, the modifiers are exposed via a single method.
Issue ISO-IEC-9995:: Have you coordinated this set with that defined by ISO/IEC 9995 which addresses various Keyboard symbol issues.
Resolution: Upon examination of the ISO spec we found it to be insufficient to our needs. It does not represent the left/right differentiation between some keys. It also lacks function keys.
Issue ISO-IEC-14755:: Review ISO/IEC 14755 "Input methods to enter characters from the repertoire of ISO/IEC 10646 with a keyboard or other input device" to insure that the treatment of input state is consistent with that expected by current practice when it comes to platforms which support input methods.
Issue offsets:: (This issue is related with mouse events and Views?)
it would be useful if MouseEvent class had a property that would enable listners to learn about coordinates of the event within the element's own coordinate system.
Resolution: We are not doing views at the momewnt.
Issue unicodeidents:: Some of the unicode chars are pretty esoteric (i.e. home, end, scroll lock). Do we want to adopt these or will this be harder on users than defining them in the DOM Event Spec. About a dozen keys fit this pattern.
Resolution: There are use cases to keep them.
Issue texteventwithoutchargeneration:: The results of the discussions on switching the keypress event out for the textEvent were inconclusive on the question of whether to fire textEvents for non character generating keys input. This includes modifier keys, function keys, etc.
Resolution: There are use cases to keep them.
Issue public0198-1:: From 0198, being able to manipulate the "default" group using EventGroup functions?
Resolution: Non-groups methods can always be used to access the default group. We didn't find a good reason to have access to the default group through the groups methods for the moment.
Issue public0198-2:: From 0198, no dispatchEvent for a specific group?
Resolution: The default and correct behavior is to dispatch the event on all listeners, independently from the groups. We think we should stick with this model without further reasons.
Issue public0198-3:: From 0198, assume that dispatchEvent's return value would be false if any listener in any group called preventDefault?
Resolution: Yes. (no change in the spec)
Issue public0198-4:: From 0198, you could potentially add the same listener to the same event target on multiple groups. Should the Event or EventListener interface be extended so that you could detect which group is active?
Resolution: We didn't find good use cases to do so for the moment.
Issue public0279-1:: From 0279, event types and case sensitivity.
Resolution: Event.type returns event names in lowercase.
Issue public0283-1:: From 0283, an implementation can support the MutationEvents module even if it never fires anything more specific than DOMSubtreeModified events. Furthermore, although it is not recommended, an implementation may legally choose to fire an event of this type only after every 100 modifications to the document, or every 30 seconds if any changes have happened during that interval.
Resolution: Yes, the spec doesn't prevent to do so. (no change in the spec)
Issue public0294-1:: From 0294, handleEvent should be allowed to throw exceptions given that the dispatch is ignoring them.
Issue public0294-2:: From 0294, if a user provides his own implementation of Event instead of using createEvent, how does the DOM implementation do to set the currentTarget or phase? (see also 0296)
Resolution: A new CustomEvent interface was added in the draft.
Issue public0294-3:: From 0294, Name collisions between EventTarget.addEventListener() and EventTargetGroup.addEventListener() and removeEventListener*s()
Resolution: Fixed.
Issue public0294-4:: From 0294, method of creating generic Event (i.e. createEvent("Events")) in case you want to use Event dispatching, but don't care if the implementation supports any other feature. createEvents("Events") could return whatever implementation that was most convienient for it. For example, an HTML implementation could return an object that coincidentally supported HTMLEvent.
Resolution: Yes. we don't prevent that. (no change in the spec)
Issue public0294-5:: From 0294, merge the Event groups with the existing interfaces, don't create new ones.
Resolution: Done.
Issue public0295-1:: From 0295, should we rename the event "textEvent" to "text"?
Resolution: "textInput"
Issue public0295-2:: From 0295, include a note that explains the interaction between addEventListener(), removeEventListener() and eventListenerList.item(). Does removeEventListener() preserve the order of the registered event listeners that are not removed? Are EventListenerList live?
Resolution: Fixed: unordered and not lived.
Issue public0296-1:: From 0296, hasFeature("MouseEvents", "3.0") returns true and similar passages imply that level 2 implementations don't support the corresponding event modules, since they would return false to hasFeature(modulename,"3.0"). They do support it, just not at the L3 version. An L3 version of an L2 introduced module, should return true if the version is null, "", "2.0" or "3.0".
Resolution: Fixed.
Issue public0296-2:: From 0296, It might be useful to cause a call to init*Event() after dispatch has started to raise an exception. Dispatching an event a second time should also raise an exception.
Resolution: waiting for a use case and clarification.
Issue public0301:: From 0301, the capture phase can't be disabled. text is misleading.
Resolution: clarified.

1. Document Object Model Events

Table of contents

1.1. Overview of the DOM Level 3 Event Model

1.1.1. Terminology

1.2. Description of event flow

1.2.1. Event listeners activation

1.2.2. Event capture

1.2.3. Event bubbling

1.2.4. Event cancelation

1.2.5. EventListener Grouping

1.3. Event listener registration

1.3.1. Event registration interfaces

1.3.2. Interaction with HTML 4.0 event listeners

1.4. Basic interfaces

1.4.1. Event creation

1.5. Event module definitions

1.5.1. User Interface event types

1.5.2. Mouse event types

1.5.3. Text events

1.5.4. Mutation event types

1.5.5. HTML event types

1.6. Issues