This document specifies an event flow for tree-based structures: . While it is expected that HTML and XML applications will follow this event flow, applications might reuse the interfaces defined in this document for non tree-based structures. In that case, it is the responsibility of such applications to define their event flow and how it relates to the . An example of such use can be found in .

An implementation is DOM Level 3 Events conformant if it supports the Core module defined in , the and the interfaces with their associated semantics defined in . An implementation conforms to a DOM Level 3 Events module if it conforms to DOM Level 3 Events and the event types defined in the module. An implementation conforms to an event type if it conforms to its associated semantics and DOM interfaces. For example, an implementation conforms to the DOM Level 3 User Interface Events module (see ) if it conforms to DOM Level 3 Events (i.e. implements all the basic interfaces), can generate the event types DOMActivate, DOMFocusIn, DOMFocusOut, focus, and blur accordingly to their semantics, supports the UIEvent interface, and conforms to the DOM Level 2 Core module.

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 DOM Level 3 Events is supported by the implementation. In order to fully support DOM Level 3 Events, an implementation must also support the "Core" feature defined in the DOM Level 2 Core specification and use the . For additional information about conformance, please see the DOM Level 3 Core specification . DOM Level 3 Events is built on top of DOM Level 2 Events , i.e. a DOM Level 3 Events implementation where hasFeature("Events", "3.0") returns true must also return true when the version number is "2.0", "" or, null.

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

The event is dispatched following a path from the root of the tree to this target node. It can then be handled locally at the target node level or from any target's ancestors higher in the tree. The event dispatching (also called event propagation) occurs in three phases and the following order:

The target's ancestors are determined before the initial dispatch of the event. If the target node is removed during the dispatching, or a target's ancestor is added or removed, the event propagation will always be based on the target node and the target's ancestors determined before the dispatch.

Some events may not necessarily accomplish the three phases of the DOM event flow, e.g. the event could only be defined for one or two phases. As an example, events defined in this specification will always accomplish the capture and target phases but some will not accomplish the bubbling phase ("bubbling events" versus "non-bubbling events", see also the Event.bubbles attribute).

Each node encountered during the dispatch of the event may contain event listeners.

An event type could be part of one or more categories. A category is represented using a local name and a namespace URI as defined in . The event types defined in this specification are not associated with one or more event categories and this specification does not provide methods to associate them. Other specifications may create and associate event categories with event listeners but in such case would need to inform the dispatch mechanism of those event categories. An example of the use of categories is given at .

Depending on the level of DOM support, or the devices used for display (e.g. screen) or interaction (e.g., mouse, keyboard, touch screen, and voice), these event types can be generated by the implementation. When used with an or application, the specifications of those languages may restrict the semantics and scope (in particular the possible target nodes) associated with an event type. Refer to the specification defining the language used in order to find those restrictions or to find event types that are not defined in this document.

The following table provides a non-normative summary of the event types defined in this specification. All event types are in no namespace and this specification refers to them by their local name only. All events will accomplish the capture and target phases, but not all of them will accomplish the bubbling phase (see also ). Some events are not cancelable (see ). Some events will only be dispatched to a specific set of possible targets, specified using node types. Contextual information related to the event type is accessible using DOM interfaces.

As an example, the event load will trigger event listeners attached on Element nodes for that event and on the capture and target phases. This event cannot be cancelled. If an event listener for the load event is attached to a node other than Document or Element nodes, or if it is attached to the bubbling phase only, this event listener cannot be triggered.

The event objects associated with the event types described above may contain context information. Refer to the description of the DOM interfaces for further information.

Namespace URIs were only introduced in DOM Level 3 Events and were not part of DOM Level 2 Events. All event types in this specification are defined to be in no namespace, DOM Level 2 methods have been modified to refer to event types in no namespace when adding or removing event listeners and initializing event objects, and new methods have been added to provide equivalent functionality for event types in a namespace. A future draft of this document will provide guidelines on defining new event types.

DOM Level 3 Events considers the Event.type attribute to be case-sensitive, while DOM Level 2 Events considers Event.type to be case-insensitive.

The user can attach an event listener using the methods on the EventTarget interface:

The methods do not provide the ability to register the same event listener more than once for the same event type and the same phase. It is not possible to register an event listener:

To register an event listener, DOM applications use the methods EventTarget.addEventListener() and EventTarget.addEventListenerNS().

An EventListener being registered on an EventTarget may choose to have that EventListener triggered during the capture phase by specifying the useCapture parameter of the EventTarget.addEventListener() or EventTarget.addEventListenerNS() methods to be true. If false, the EventListener will be triggered during the target and bubbling phases.

In , event listeners are attached using elements and attributes:

Event listeners can only be registered on Element nodes, other Node types are not addressable, and cannot be registered for a specific group either, they are always attached to the default group. The target phase and the bubbling phase are coupled during the registration. does not address namespaces in event types.

In , event listeners are attached using elements:

Event listeners can only be registered on Element nodes, other Node types are not addressable, and cannot be registered for a specific group either, they are always attached to the default group. The target phase and the bubbling phase are coupled during the registration. does not address namespaces in event types but uses the notion of event categories. The event type "connection.disconnect.hangup" could be associated to the event categories {"http://www.example.org/2003/voicexml", "connection"} and {"http://www.example.org/2003/voicexml", "connection.disconnect"}.

In languages such as , , or , event listeners are specified as attributes:

Since only one attribute with the same name can appear on an element, it is not possible to register more than one event listener on a single EventTarget for the event type. Also, event listeners can only be registered on Element nodes for the target phase and bubbling phase, other Node types and the capture phase are not addressable with these languages. Event listeners cannot be registered for a specific group either, they are always attached to the default group.

In most cases, the events dispatched by the DOM Events implementation are also created by the implementation. It is however possible to simulate events such as mouse events by creating the Event objects and dispatch them using the DOM Events implementation.

Creating Event objects that are known to the DOM Events implementation is done using DocumentEvent.createEvent(). The application must then initialize the object by calling the appropriate initialization method before invoking EventTarget.dispatchEvent(). The Event objects created must be known by the DOM Events implementation; otherwise an event exception is thrown.

The User Interface event module contains basic event types associated with user interfaces.

The User Interface event types are listed below. 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 DOM Level 3 User Interface event module are 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 . For additional information about conformance, please see the DOM Level 3 Core specification . The DOM Level 3 User Interface Events module is built on top of the DOM Level 2 User Interface Events module, i.e. a DOM Level 3 User Interface Events implementation where hasFeature("UIEvents", "3.0") returns true must also return true when the version number is "2.0", "" or, null.