This is a Working
Draft for review by W3C members and other interested
parties.

It is a draft document and may be updated, replaced or obsoleted
by other documents at any time. It is inappropriate to use W3C
Working Drafts as reference material or to cite them as other than
"work in progress". This is work in progress and does not imply
endorsement by, or the consensus of, either W3C or members of the
DOM Working Group.

W3C Copyright Notices and
Licenses

This document is published under the W3C® Document
Copyright Notice and License. The bindings within this document
are published under the W3C® Software
Copyright Notice and License. The software license requires
"Notice of any changes or modifications to the W3C files, including
the date changes were made." Consequently, modified versions of the
DOM bindings must document that they do not conform to the W3C
standard; in the case of the IDL definitions, the pragma prefix can
no longer be 'w3c.org'; in the case of the Java language binding,
the package names can no longer be in the 'org.w3c' package.

Public documents on the W3C site are provided by the copyright
holders under the following license. By using and/or copying this
document, or the W3C document from which this statement is linked,
you (the licensee) agree that you have read, understood, and will
comply with the following terms and conditions:

Permission to copy, and distribute the contents of this
document, or the W3C document from which this statement is linked,
in any medium for any purpose and without fee or royalty is hereby
granted, provided that you include the following on ALL
copies of the document, or portions thereof, that you use:

When space permits, inclusion of the full text of this
NOTICE should be provided. We request that authorship
attribution be provided in any software, documents, or other items
or products that you create pursuant to the implementation of the
contents of this document, or any portion thereof.

No right to create modifications or derivatives of W3C documents
is granted pursuant to this license. However, if additional
requirements (documented in the Copyright FAQ) are
satisfied, the right to create modifications or derivatives is
sometimes granted by the W3C to individuals complying with those
requirements.

THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO
REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY
PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT,
SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE
DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS
THEREOF.

The name and trademarks of copyright holders may NOT be used in
advertising or publicity pertaining to this document or its
contents without specific, written prior permission. Title to
copyright in this document will at all times remain with copyright
holders.

This work (and included software, documentation such as READMEs,
or other related items) is being provided by the copyright holders
under the following license. By obtaining, using and/or copying
this work, you (the licensee) agree that you have read, understood,
and will comply with the following terms and conditions.

Permission to copy, modify, and distribute this software and its
documentation, with or without modification, for any purpose and
without fee or royalty is hereby granted, provided that you include
the following on ALL copies of the software and documentation or
portions thereof, including modifications:

The full text of this NOTICE in a location viewable to users of
the redistributed or derivative work.

Any pre-existing intellectual property disclaimers, notices, or
terms and conditions. If none exist, the W3C® Short
Software Notice should be included (hypertext is preferred,
text is permitted) within the body of any redistributed or
derivative code.

Notice of any changes or modifications to the files, including
the date changes were made. (We recommend you provide URIs to the
location from which the code is derived.)

THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS," AND
COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE
USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD
PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT,
SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE
SOFTWARE OR DOCUMENTATION.

The name and trademarks of copyright holders may NOT be used in
advertising or publicity pertaining to the software without
specific, written prior permission. Title to copyright in this
software and any associated documentation will at all times remain
with copyright holders.

1.1. Introduction

DOM Events is designed with two main goals. The first goal is
the design of an event system which allows
registration of event listeners, describes event flow through a
tree structure. 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 DOM Events 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 specification define both the
specification for the DOM Event Model and a number of conformant
event modules designed for use within the model. The DOM Event
Model consists of:

The DOM event flow, which
describe the flow of events in a tree-based structure.

A set of interfaces to access contextual information on events,
to register event listeners.

1.1.1. Event flows

This document specifies an event flow for tree-based structures:
DOM event flow. 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 structure. In that case, it is the
responsibility of such application to define their event flow and
how it relates to the DOM event
flow. As example of such use could be found in [DOM Level 3 Load
and Save].

1.1.2. Conformance

An implementation is DOM Level 3 Events conformant if it
supports the Core module defined in [DOM Level 2 Core], the DOM event flow and the interfaces
with their associated semantics defined in Basic interfaces. 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 User Interface event
types) if it conforms to DOM Level 3 Events (i.e. implements
all the basic interfaces), can generate the event types
{"http://www.w3.org/2001/xml-events", "DOMActivate"}{"http://www.w3.org/2001/xml-events", "DOMFocusIn"}{"http://www.w3.org/2001/xml-events", "DOMFocusOut"}
accordingly to their semantics, supports the UIEvent interface,
and conforms to DOM Level 2 Core module.

Note: An implementation which does not conform to an
event module can still implement the DOM interfaces associated with
it. The DOM application can then create an event object using the
DocumentEvent.createEvent
method and dispatch an event type associated with this interface
using the EventTarget.dispatchEvent
method.

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 [DOM Level 2 Core] and use the DOM event flow. For additional
information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core]. DOM Level 3 Events
is built on top of DOM Level 2 Events [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.

1.2. DOM event flow

The DOM event
flow is the process through which the event originates from the DOM
Events implementation and is dispatched into a tree. Each event has
an event
target, a targeted node in the case of the DOM Event flow,
toward which the event is dispatched by the DOM Events
implementation.

1.2.1. Phases

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 ancestor higher in the tree. The event
dispatching (also called event propagation) occurs in three
phases:

The capture
phase: the event is dispatched on the target ancestors
from the root of the tree to the direct parent of the target node.

The target ancestors are determined before the initial dispatch
of the event. If the target node is removed during the dispatching,
or a target ancestor is added or removed, the event propagation
will always be based on the target node and the target 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).

1.2.2. Event
listeners

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

1.2.2.1.
Registration of event listeners

Event listeners can be registered on all nodes in the tree for a
specific type of event, phase, and group. If the event listener is
registered on a node while an event gets processed on this node,
the event listener will not be triggered during the current phase
but may be triggered during a later phase in the event flow, i.e.
the bubbling
phase.

1.2.2.2. Event groups

An event listener is always part of a group. It is either
explicitly in a group if a group has been specified at the
registration or implicitly in the default group if no group has
been specified. Within a group, event listeners are ordered in
their order of registration. If two event listeners {A1, A2}, that
are part of the same group, are registered one after the other (A1,
then A2) for the same phase, the DOM event flow guarantees their
triggering order (A1, then A2). If the two listeners are not part
of the same group, no specification is made as to the order in
which they will be triggered.

Note: While this specification does not specify a full
ordering (i.e. groups are still unordered), it does specify
ordering within a group. This implies that if the event listeners
{A1, A2, B1, B2}, with A and B being two different groups, are
registered for the same phase in the following order: A1, A2, B1,
and B2. The following triggering orders are possible and conform to
the DOM event flow: {A1, A2, B1, B2}, {A1, B1, A2, B2}, {B1, A1,
A2, B2}, {A1, B1, B2, A2}, {B1, A1, B2, A2}, {B1, B2, A1, A2}. DOM
Events implementations may impose priorities on groups but DOM
applications must not rely on it. Unlike this specification, [DOM
Level 2 Events] did not specify any triggering order for event
listeners.

1.2.2.3.
Triggering an event listener

When the event is dispatched through the tree, from node to
node, event listeners registered on the node are triggered if:

they were registered for the same type of event;

they were registered for the same phase;

the event propagation has not been stopped for the group.

1.2.2.4. Removing
an event listener

If an event listener is removed from a node while an event is
being processed on the node, it will not be triggered by the
current actions. Once removed, the event listener is never invoked
again (unless registered again for future processing).

1.2.2.5.
Reentrance

It is expected that actions taken by EventListeners
may cause additional events to be dispatched. Additional events
should be handled in a synchronous manner and may cause reentrance
into the event model. If an event listener fires a new event using
EventTarget.dispatchEvent,
the event propagation that causes the event listener to be
triggered will resume only after the event propagation of the new
event is completed.

Since implementations may have restrictions such as stack-usage
or other memory requirements, applications should not depend on how
many synchronous events may be triggered.

1.2.2.6.
Event propagation and event groups

All event listeners are part of a group (see Registration of event
listeners). An event listener may prevent event listeners that
are part of a same group from being triggered. The effect could
be:

immediate and no more event listeners from the same group will
be triggered by the event object;

differed until all event listeners from the same group have
been triggered on the current node, i.e. the event listeners of the
same group attached on other nodes will not be triggered.

If two event listeners are registered for two different groups,
one cannot prevent the other from being triggered.

1.3. Default
actions and cancelable events

Implementations may have a default action associated with an
event type. An example is the [HTML 4.01] form element. When the user
submits the form (e.g. by pressing on a submit button), the event
{"http://www.w3.org/2001/xml-events", "submit"} is
dispatched to the element and the default action for this event
type is generally to send a request to a Web server with the
parameters from the form.

The default actions are not part of the DOM Event flow. Before
invoking a default action, the implementation must first dispatch
the event as described in the DOM
event flow.

A
cancelable event is an event associated with a default
action which is allowed to be canceled during the DOM event flow.
At any phase during the event flow, the triggered event listeners
have the option of canceling the 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. Not all events defined in this
specification are cancelable events.

Different implementations will specify their own default
actions, if any, associated with each event. The DOM Events
specification does not attempt to specify these actions.

This specification does not provide mechanisms for accessing
default actions or adding new ones.

Note: Some implementations also provide default actions
before the dispatch of the event. It is not possible to
cancel those default actions and this specification does not
address them. An example of such default actions can be found in
[DOM
Level 2 HTML] on the HTMLInputElement.checked
attribute.

1.4. Event types

Each event is associated with a type, called event type.
The event type is composed of a local name and a namespace URI as
defined in [XML Namespaces]. All events
defined in this specification use the namespace URI
"http://www.w3.org/2001/xml-events".

Note: As in [DOM Level 3 Core], DOM Level 3 Events
does not perform any URI normalization or canonicalization. The
URIs given to the DOM are assumed to be valid (e.g., characters
such as white spaces are properly escaped), and no lexical checking
is performed. Absolute URI references are treated as strings and compared
literally. How relative namespace URI references are
treated is undefined. To ensure interoperability only absolute
namespace URI references (i.e., URI references beginning with a
scheme name and a colon) should be used. Applications that wish to
have no namespace should use the value null as the
namespaceURI parameter of methods. If they pass an empty string the
DOM implementation turns it into a null.

1.4.1. Complete
list of event types

Depending on the level of DOM support, or the devices used to
display (e.g. screen) or interact with (e.g. mouse, keyboard, touch
screen, voice, ...), these event types could be generated by the
implementation. When used with an [XML 1.0] or [HTML 4.01]
application, the specifications of those languages may restrict the
semantics and scope (in particular the possible target nodes)
associated with an event type. For example,
{"http://www.w3.org/2001/xml-events", "click"} can be
targeted to all [XHTML 1.0] elements but applet, base,
basefont, bdo, br, font, frame, frameset, head, html, iframe,
isindex, meta, param, script, style, and title. 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 defines all event types provided in this
specification (with the exception of two event types preserved for
backward compatibility with [HTML 4.01]). All events will
accomplish the capture phase and target phases, but not all of them
will accomplish the bubbling phase (see also DOM event flow). Some events are not
cancelable
(see Default actions
and cancelable events). Contextual information related to the
event type are accessible using DOM interfaces.

Event type

Description

Bubbling phase

Cancelable

Target node

DOM interface

"http://www.w3.org/2001/xml-events",
"DOMActivate"

An element is activated,
for instance, using a mouse device, a keyboard device, or a voice
command.

Note: The activation of an element is device dependent
but is also application dependent, e.g. a link in a document can be
activated using a mouse click or a mouse double click.

One or more characters
have been entered. The characters can originate from a variety of
sources. For example, it could be a character resulting from a key
being pressed or released on a keyboard device, a character
resulting from the processing of an input method editor, or resulting
from a voice command.

A pointing device button
is clicked over an element. The definition of a click depends on
the environment configuration; i.e. may depend on the screen
location or the delay between the press and release of the pointing
device button. In any case, the target node must be the same
between the mousedown, mouseup, and click. The sequence of these
events is: {"http://www.w3.org/2001/xml-events",
"mousedown"}, {"http://www.w3.org/2001/xml-events",
"mouseup"}, and {"http://www.w3.org/2001/xml-events",
"click"}. Note that, given the definition of a click, If one
or more of the event types
{"http://www.w3.org/2001/xml-events", "mouseover"},
{"http://www.w3.org/2001/xml-events", "mousemove"},
and {"http://www.w3.org/2001/xml-events", "mouseout"}
occur between the press and release of the pointing device button,
the event type {"http://www.w3.org/2001/xml-events",
"click"} cannot occur. In the case of nested elements, this
event type is always targeted at the most deeply nested
element.

A key is pressed down.
This event type is device dependent and relies on the capabilities
of the input devices and how they are mapped in the operating
system. This event type is generated after the keyboard mapping but
before the processing of the input
method editor. This event should logically happen before
the event {"http://www.w3.org/2001/xml-events",
"keyup"} is produced.

A key is released. This
event type is device dependent and relies on the capabilities of
the input devices and how they are mapped in the operating system.
This event type is generated after the keyboard mapping but before
the processing of the input method
editor. This event should logically happen after the event
{"http://www.w3.org/2001/xml-events", "keydown"} is
produced.

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
dispatched 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 accommodate 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(s) have occurred.

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 node of this
event type is the node being removed. If the node is being directly
removed, the event type {"http://www.w3.org/2001/xml-events",
"DOMNodeRemoved"} will fire before this event type.

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 node of this
event is the node being inserted. If the node is being directly
inserted, the event type
{"http://www.w3.org/2001/xml-events",
"DOMNodeInserted"} will fire before this event type.

Occurs after an
Attr has been modified on a node. The target node of this
event is the parent Element node whose
Attr changed. 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.

Occurs after
CharacterData.data or
ProcessingInstruction.data have been modified but the
node itself has not been inserted or deleted. The target node of this
event is the CharacterData node or the
ProcessingInstruction node.

Occurs after the
namespaceURI and/or the nodeName of a
Attr node have been modified (e.g., the attribute was
renamed using Document.renameNode). The target of this
event is the parent Element node whose
Attr has been renamed.

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.

1.4.2.
Compatibility with DOM Level 2 Events

Namespace
URIs Were only introduced in DOM Level 3 Events and were
not part of DOM Level 2 Events. DOM Level 2 Events methods are
namespace ignorant and the event type is only represented by an XML name, specified
in the Event.type
attribute.

Therefore, while it is safe to use these methods when not
dealing with namespaces, using them and the new ones at the same
time should be avoided. DOM Level 2 Events methods solely identify
events by their Event.type. On the
contrary, the DOM Level 3 Events methods related to namespaces,
identify attribute nodes by their Event.namespaceURI
and Event.type.
Because of this fundamental difference, mixing both sets of methods
can lead to unpredictable results. For example, using EventTarget.addEventListenerNS,
two event listeners (or more) could be registered using the same
type and same useCapture values, but
different namespaceURIs. Calling EventTarget.removeEventListener
with that type and useCapture could then
remove any or none of those event listeners. The result depends on
the implementation. The only guarantee in such cases is that all
methods which access an event listener by its
namespaceURI and type will access the
same event listener. For instance, EventTarget.removeEventListenerNS
removes the event that EventTarget.addEventListenerNS
added.

For compatibility reasons, the dispatching of an event will
ignore namespace URIs if either the event or the event listener has
a null namespace URI. If a DOM Level 2 event (i.e.
with a null namespace URI) is dispatched in the DOM
tree, all event listeners that match the type will be
triggered as described in the DOM
event flow. If a DOM Level 3 event (i.e. with a namespace URI)
is dispatched in the DOM tree, all event listener with the same
type and the same or null namespace URI, will be
triggered as described in the DOM
event flow.

1.5. Event listener
registration

Note: This section is informative.

There are mainly two ways to associate an event listener to a
node in the tree:

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. The target
phase and the bubbling phase are
coupled during the registration, i.e. it is not possible to
register an event listener for only one of these two phases (but
the listener itself could ignore events during one of these phases
if desired). It is also not possible to register an event listener
for a specific event target and have it only triggered for this
event target during the bubbling or capture phases (but again, the
listener itself could ignore events with other event targets if
desired).

1.5.2. Using
XML Events

Event listeners can only be registered on Element
nodes, i.e. other Node types are not addressable, and
cannot be registered for a specific group either, i.e. they are
always attached to the default group. [XML
Events] does not address namespaces in event types. If the
value of the event attribute of the
listener element contains a colon (':'), it should be
interpreted as a QName as defined in [XML Schema
Part 2].

1.5.3. Using
XML or HTML attributes

Since only one attribute with the same name can appear on an
element, it is therefore 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,
i.e. other Node types and the capture phase are not
addressable with these languages. Event listeners cannot be
registered for a specific group either, i.e. they are always
attached to the default group.

In order to achieve compatibility with those languages,
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. Furthermore, no specification is
made as to the order in which event attributes will receive the
event with regards to the other EventListeners
on the EventTarget.

1.6. Basic
interfaces

The interfaces described in this section are fundamental to DOM
Level 3 Events and must always be supported by the
implementation.

The Event interface is used to provide contextual
information about an event to the listener processing the event. An
object which implements the Event interface is passed
as the parameter to an EventListener.
More specific context information is passed to event listeners by
deriving additional interfaces from Event which
contain information directly relating to the type of event they
represent. These derived interfaces are also implemented by the
object passed to the event listener.

Used to indicate whether or not an event can have its default
action prevented (see also Default actions and
cancelable events). If the default action can be prevented the
value is true, otherwise the value is
false.

Used to indicate the EventTarget whose
EventListeners
are currently being processed. This is particularly useful during
the capture and bubbling phases. This attribute could contain the
target node or
a target ancestor when used with the DOM event flow.

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.

The name must be an NCName
as defined in [XML Namespaces] and is
case-sensitive. The character ":" (colon) should not be used in
this attribute.
If the attribute Event.namespaceURI
is different from null, this attribute represents a local name.

The initEvent method is used to
initialize the value of an Event created through the
DocumentEvent.createEvent
method. This method may only be called before the
Event has been dispatched via the EventTarget.dispatchEvent
method. If the method is called several times before invoking EventTarget.dispatchEvent,
only the final invocation takes precedence. If called from a
subclass of Event interface only the values specified
in this method are modified, all other attributes are left
unchanged.
This method sets the Event.type
attribute to eventTypeArg, and
Event.localName and Event.namespaceURI
to null. To initialize an event with a local name and
namespace URI, use the initEventNS method.

Parameters

eventTypeArg of type
DOMString

Specifies the event type.

canBubbleArg of type
boolean

Specifies whether or not the event can bubble. This parameter
overrides the intrinsic bubbling behavior of the event.

cancelableArg of type
boolean

Specifies whether or not the event's default action can be
prevented. This parameter overrides the intrinsic cancelable
behavior of the event.

The initEventNS 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 the event has been dispatched. If called multiple times the
final invocation takes precedence. If a call to
initEventNS is made after one of the
Event derived interfaces' init methods has been
called, only the values specified in the initEventNS
method are modified, all other attributes are left unchanged.
This method sets the Event.type
attribute to eventTypeArg, and Event.namespaceURI
to namespaceURIArg.

Parameters

namespaceURIArg of type
DOMString

Specifies the namespace URI
associated with this event, or null if no
namespace.

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 (see
also Default actions
and cancelable events), and thus independently of event groups.
Calling this method for a non-cancelable event has no effect.

Note: This method does not stop the event propagation;
use stopPropagation or
stopImmediatePropagation for that effect.

This method is used to prevent event listeners
of the same group to be triggered and, unlike
stopPropagation its effect is immediate (see Event propagation and
event groups). Once it has been called, further calls to that
method have no additional effect.

Note: This method does not prevent the default action
from being invoked; use preventDefault for that
effect.

This method is used to prevent event listeners
of the same group to be triggered but its effect is differed until
all event listeners attached on the currentTarget have
been triggered (see Event propagation and
event groups). Once it has been called, further calls to that
method have no additional effect.

Note: This method does not prevent the default action
from being invoked; use preventDefault for that
effect.

The EventTarget interface is implemented by all the
objects which could be event targets in an
implementation which supports the Event flows. The interface allows
registration, removal or query of event listeners, and dispatch of
events to an event target.

When used with DOM event
flow, this interface is implemented by all target nodes and target
ancestors, i.e. all DOM Nodes of the tree support this
interface when the implementation conforms to DOM Level 3 Events
and, therefore, this interface can be obtained by using
binding-specific casting methods on an instance of the
Node interface.

When using addEventListener or
addEventListenerNS, 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.

The listener parameter takes an object implemented
by the user which implements the EventListener
interface and contains the method to be called when the event
occurs.

useCapture of type
boolean

If true, useCapture indicates that the user wishes
to add the event listener for the capture phase only,
i.e. this event listener will not be triggered during the target and bubbling phases. If
false, the event listener will only be triggered
during the target and bubbling phases.

This method allows the registration of an event
listener in a specified group or the default group and, depending
on the useCapture parameter, on the capture phase of
the DOM event flow or its target and bubbling phases.

Parameters

namespaceURI of type
DOMString

Specifies the Event.namespaceURI
associated with the event for which the user is registering.

type of type
DOMString

Specifies the Event.type
associated with the event for which the user is registering.

The listener parameter takes an object implemented
by the user which implements the EventListener
interface and contains the method to be called when the event
occurs.

useCapture of type
boolean

If true, useCapture indicates that the user wishes
to add the event listener for the capture phase only,
i.e. this event listener will not be triggered during the target and bubbling phases. If
false, the event listener will only be triggered
during the target and bubbling phases.

It is necessary to have an exception that occurs if the
specified event is not an event which the implementation knows how
to dispatch, if it was not created by calling DocumentEvent.createEvent
and Event.isCustom() is false.
NOT_SUPPORTED?

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

DISPATCH_REQUEST_ERR: Raised if the Event object is already
being dispatched in the tree.

This method allows the DOM application to know
if this EventTarget 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 an event
listener (see willTriggerNS).

This method allows the removal of event
listeners from the default group.
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 for
which the user registered the event listener.

Specifies whether the EventListener
being removed was registered for the capture phase or not. If a
listener was registered twice, once for the capture phase and once
for the target and bubbling phases, each must be removed
separately. Removal of an event listener registered for the capture
phase does not affect the same event listener registered for the
target and bubbling phases, and vice versa.

This method allows the removal of event
listeners from a specified group or the default group.
Calling removeEventListenerNS with arguments which do
not identify any currently registered EventListener
on the EventTarget has no effect.

Parameters

namespaceURI of type
DOMString

Specifies the Event.namespaceURI
associated with the event for which the user registered the event
listener.

type of type
DOMString

Specifies the Event.type
associated with the event for which the user registered the event
listener.

Specifies whether the EventListener
being removed was registered for the capture phase or not. If a
listener was registered twice, once for the capture phase and once
for the target and bubbling phases, each must be removed
separately. Removal of an event listener registered for the capture
phase does not affect the same event listener registered for the
target and bubbling phases, and vice versa.

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.

The EventListener interface is the primary way for
handling events. Users implement the EventListener
interface and register their event listener on an EventTarget. The
users should also remove their EventListener from its
EventTarget after
they have completed using the listener.

Copying a Node does not copy the event listeners
attached to it. Event listeners must be attached to the newly
created Node afterwards if so desired. Therefore,
Nodes are copied using Node.cloneNode or
Range.cloneContents, the EventListeners
attached to the source Nodes are not attached to their
copies.

Moving a Node does not affect the event listeners
attached to it. Therefore, when Nodes are moved using
Document.adoptNode, Node.appendChild, or
Range.extractContents, the EventListeners
attached to the moved Nodes stay attached to them.

Event listeners can be registered using
Event.addEventListenerNS within a group.

When a set of actions associated with event listeners is
critical for an application such as refreshing the display, it is
important to separate them from other event listeners who might
stop the event flow. In order to prevent undesirable side effects,
the application should create a group using DocumentEvent.createEventListenerGroup
and use it when adding or removing event listeners.

If the Event.type was not
specified by initializing the event before the method was called.
Specification of the Event.type as
null or an empty string will also trigger this
exception.

1.6.1. Event creation

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.

DOM Events provides two ways for creating Event objects. An
application can either create Event objects that are
known to the implementation, or create its own objects and have
them dispatched by 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 DOM application might want to create its own Event objects, in order
to change the default Event implementation
provided by the DOM Events implementation or to generate new event
types with specific contextual information. In any case, the
application is responsible for creating and initializing the Event object. The
application can then dispatch the event using the DOM Events
implementation by using EventTarget.dispatchEvent.

However, the DOM Events implementation requires to have access
to two attributes in the Event object in order
to accomplish the dispatch appropriately: Event.currentTarget
and Event.eventPhase.
Those attributes are defined as readonly in the Event interface since
event listeners must not change them and it is the responsibility
of the DOM Events implementation to update them during the event
flow. Therefore, implementing the Event interface when
creating its own events is not enough for an application since the
DOM Events implementation will not be able to update the current
phase and the current node during the dispatch, unless the event
object also implements the CustomEvent
interface to give access to the relevant attributes.

The DocumentEvent interface provides a mechanism by
which the user can create an Event object 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.

The eventType parameter specifies the name of the
DOM Events interface to be supported by the created event object,
e.g. "Event", "MouseEvent",
"MutationEvent" ... If the Event is to be
dispatched via the EventTarget.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 DocumentEvent.createEvent
with the parameter "UIEvent". The UIEvent.initUIEventNS
method could then be called on the newly created UIEvent object
to set the specific type of user interface event to be dispatched,
{"http://www.w3.org/2001/xml-events", "DOMActivate"}
for example, and set its context information, e.g. UIEvent.detail
in this example.
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 EventTarget.dispatchEvent
method. However, the DOM implementation needs access to the
attributes Event.currentTarget
and Event.eventPhase
to propagate appropriately the event in the DOM tree. Therefore
users' Event implementations
might need to support the CustomEvent
interface for that effect.

The CustomEvent interface gives access to the
attributes Event.currentTarget
and Event.eventPhase.
It is intended to be used by the DOM Events implementation to
access the underlying current target and event phase while
dispatching a custom Event in the tree; it
is intended to be implemented, and not used, by DOM
applications.

The methods contained in this interface are not intended to be
used by a DOM application, especially during the dispatch on the Event object.
Changing the current target or the current phase may conduct into
unpredictable results of the event flow. The DOM Events
implementation should ensure that both methods return the
appropriate current target and phase before invoking each event
listener on the current target to protect DOM applications from
malicious event listeners.

Note: If this interface is supported by the event object,
Event.isCustom() must return true.

The isImmediatePropagationStopped
method is used by the DOM Events implementation to know if the
method stopImmediatePropagation() has been called for
this event in the current group. It returns true if
the method has been called, false otherwise.

Return Value

boolean

true if the event propagation has been stopped
immediately in the current group.

1.7. Event module
definitions

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

The initUIEvent method is used to
initialize the value of a UIEvent created using the DocumentEvent.createEvent
method. This method may only be called before the
UIEvent has been dispatched via the EventTarget.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. This parameter
overrides the intrinsic bubbling behavior of the event.

cancelableArg of type
boolean

Specifies whether or not the event's default action can be
prevented. This parameter overrides the intrinsic cancelable
behavior of the event.

The initUIEventNS method is used
to initialize the value of a UIEvent created using the
DocumentEvent.createEvent
method. This method may only be called before the
UIEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times during that phase if
necessary. If called multiple times, the final invocation takes
precedence.

Parameters

namespaceURI of type
DOMString

Specifies the namespace URI
associated with this event, or null if the application
wish not to use namespaces.

typeArg of type
DOMString

Specifies the event type (see also the description of the
type attribute in the Event interface).

The User Interface event types are listed below. For a full
description of the semantics associated with these event types,
refer to the Complete list of event
types. 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 types 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 [DOM Level 2
Views]. For additional information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core]. The DOM Level 3
User Interface Events module is built on top of the DOM Level 2
User Interface Events [DOM Level 2 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.

Event type

Context information

"http://www.w3.org/2001/xml-events",
"DOMActivate"

UIEvent.view is
in use. UIEvent.detail
contains a numerical value 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).

1.7.2. Text
events

The text event module originates from the [HTML 4.01]
onkeypress attribute. Unlike this attribute, the event
type {"http://www.w3.org/2001/xml-events",
"textInput"} applies only to characters and is specifically
designed for use with text input devices.

The initTextEvent method is used
to initialize the value of a TextEvent created using
the DocumentEvent.createEvent
method. This method may only be called before the
TextEvent has been dispatched via the EventTarget.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. This parameter
overrides the intrinsic bubbling behavior of the event.

cancelableArg of type
boolean

Specifies whether or not the event's default action can be
prevent. This parameter overrides the intrinsic cancelable behavior
of the event.

The initTextEventNS method is used
to initialize the value of a TextEvent created using
the DocumentEvent.createEvent
method. This method may only be called before the
TextEvent has been dispatched via the EventTarget.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

namespaceURI of type
DOMString

Specifies the namespace URI
associated with this event, or null if the
applications wish to have no namespace.

type 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 view.

dataArg of type
DOMString

Specifies the TextEvent's data
attribute

No Return Value

No Exceptions

The text event type is listed below. For a full description of
the semantics associated with this event type, refer to the Complete list of
event types. 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. For additional information
about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core].

1.7.3.
Mouse event types

The Mouse event module originates from the [HTML 4.01]
onclick, ondblclick,
onmousedown, onmouseup,
onmouseover, onmousemove, and
onmouseout attributes. This event module is
specifically designed for use with pointing input devices, such a
mouse.

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.

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

During mouse events caused by the depression or release of a
mouse button, button is used to indicate which mouse
button changed state. 0 indicates the normal (in
general on the left or the one button on Macintosh mice, used to
activate a button or select text) button of the mouse.
2 indicates the contextual property (in general on the
right, used to display a context menu) button of the mouse if
present. 1 indicates the extra (in general in the
middle and often combined with the mouse wheel) button. Some mice
may provide or simulate more buttons and values higher than
2 could be used to represent such buttons.

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.

The initMouseEvent method is used
to initialize the value of a MouseEvent created using
the DocumentEvent.createEvent
method. This method may only be called before the
MouseEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times before being
dispatched. If called multiple times, the final invocation takes
precedence.

The initMouseEventNS method is
used to initialize the value of a MouseEvent created
using the DocumentEvent.createEvent
interface. This method may only be called before the
MouseEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times during that phase if
necessary. If called multiple times, the final invocation takes
precedence.

Parameters

namespaceURI of type
DOMString

Specifies the namespace URI
associated with this event, or null if the application
wish to have no namespace.

Specifies whether or not alt graph key was depressed during the
Event.

No Return Value

No Exceptions

The Mouse event types are listed below. For a full description
of the semantics associated with these event types, refer to the Complete list of
event types. In the case of nested elements, mouse event types
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. 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. For additional information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core]. The DOM Level 3
Mouse Events module is built on top of the DOM Level 2 Mouse Events
[DOM
Level 2 Events] module, i.e. a DOM Level 3 Mouse Events
implementation where hasFeature("MouseEvents", "3.0")
returns true must also return true when
the version number is "2.0",
"" or, null.

As an example, a "double-click" on a mouse device will produce
the following events (the value of UIEvent.detail
is indicated in parenthesis):

{"http://www.w3.org/2001/xml-events", "mousedown"}
(1)

{"http://www.w3.org/2001/xml-events", "mouseup"}
(1)

{"http://www.w3.org/2001/xml-events", "click"}
(1)

{"http://www.w3.org/2001/xml-events", "mousedown"}
(2)

{"http://www.w3.org/2001/xml-events", "mouseup"}
(2)

{"http://www.w3.org/2001/xml-events", "click"}
(2)

(ED: plh -- I added this
example above but didn't check if it is correct or not yet (do we
have the click(1)?). If it is not, let me know in any case. I'll
probably complicate the example a bit (with moves) to show how
detail really works. )

1.7.4.
Keyboard event types

Keyboard events are device dependent, i.e. they rely on the
capabilities of the input devices and how they are mapped in the
operating systems. It is therefore highly recommended to rely on Text events when dealing
with characters.

The KeyboardEvent interface provides specific
contextual information associated with keyboard devices. Each
keyboard event reference a key using an identifier.

Each modifier attribute (ctrlKey,
shiftKey, altKey, metaKey,
and altGraphKey) is activated when the key modifier is
being pressed down or maintained pressed, i.e. the modifier
attribute is not in use when the key modifier is being
released.

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

The key activation is not distinguished as the left or right
version of the key, and did not originate from the numeric keypad
(or did not originate with a virtual key corresponding to the
numeric keypad). Example: the 'Q' key on a PC 101 Key US.

Implementations can use this constant to indicate that the
location of the key cannot be determined.

Note: In case a DOM implementation wishes to provide new
location information, all values above the value of this constant
can be used for that effect and generic DOM applications should
consider values above the value of this constant as being
equivalent to DOM_KEY_LOCATION_UNKNOWN.

The initKeyboardEvent method is
used to initialize the value of a KeyboardEvent
created using the DocumentEvent.createEvent
method. This method may only be called before the
KeyboardEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times before being
dispatched 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. This parameter
overrides the intrinsic bubbling behavior of the event.

cancelableArg of type
boolean

Specifies whether or not the event's default action can be
prevent. This parameter overrides the intrinsic cancelable behavior
of the event.

The initKeyboardEventNS method is
used to initialize the value of a KeyboardEvent
created using the DocumentEvent.createEvent
method. This method may only be called before the
KeyboardEvent has been dispatched via the EventTarget.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

namespaceURI of type
DOMString

Specifies the namespace URI
associated with this event, or null if the
applications wish to have no namespace.

type 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 KeyboardEvent's
AbstractView.

keyIdentifierArg of type
DOMString

Specifies the KeyboardEvent's
keyIdentifier attribute

keyLocationArg of type
unsigned long

Specifies the KeyboardEvent's
keyLocation attribute.

ctrlKeyArg of type
boolean

Specifies the KeyboardEvent's ctrlKey
attribute.

shiftKeyArg of type
boolean

Specifies the KeyboardEvent's
shiftKey attribute.

altKeyArg of type
boolean

Specifies the KeyboardEvent's altKey
attribute.

metaKeyArg of type
boolean

Specifies the KeyboardEvent's metaKey
attribute.

altGraphKeyArg of type
boolean

Specifies the KeyboardEvent's
altGraphKey attribute.

No Return Value

No Exceptions

Depending on the character device generation system, keyboard
events may or may not be generated.

The keyboard event types are listed below. For a full
description of the semantics associated with these event types,
refer to the Complete list of event
types. A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "KeyboardEvents" and
"3.0" (respectively) to determine whether or not the
Keyboard 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.
For additional information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core].

1.7.5. Mutation and mutation name event types

The mutation and mutation name event modules are designed to
allow notification of any changes to the structure of a document,
including attribute, text, or name modifications. It may be noted
that none of the event types associated with the modules 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 resulted 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 dispatched. 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.

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.

The initMutationEvent method is
used to initialize the value of a MutationEvent
created using the DocumentEvent.createEvent
method. This method may only be called before the
MutationEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times before being
dispatched 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. This parameter
overrides the intrinsic bubbling behavior of the event.

cancelableArg of type
boolean

Specifies whether or not the event's default action can be
prevented. This parameter overrides the intrinsic cancelable
behavior of the event.

The initMutationEventNS method is
used to initialize the value of a MutationEvent
created using the DocumentEvent.createEvent
method. This method may only be called before the
MutationEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times during that phase if
necessary. If called multiple times, the final invocation takes
precedence.

Parameters

namespaceURI of type
DOMString

Specifies the namespace URI
associated with this event, or null if the application
wish to have no namespace.

The mutation event types are listed below. For a full
description of the semantics associated with these event types,
refer to the Complete list of event
types. 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
MutationEvent
is supported by the implementation. In order to fully support this
module, an implementation must also support the
"Events" feature defined in this specification. For
additional information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core]. This MutationEvent
interface is built on top of the DOM Level 2 Mutation Events [DOM
Level 2 Events] module, i.e. a DOM Level 3 MutationEvent
interface implementation where
hasFeature("MutationEvents","3.0") returns
true must also return true when the
version number is "2.0", ""
or, null.

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

The initMutationNameEvent method
is used to initialize the value of a MutationNameEvent
created using the DocumentEvent.createEvent
method. This method may only be called before the
MutationNameEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times during that phase if
necessary. If called multiple times, the final invocation takes
precedence.

The initMutationNameEventNS method
is used to initialize the value of a MutationNameEvent
created using the DocumentEvent.createEvent
method. This method may only be called before the
MutationNameEvent has been dispatched via the EventTarget.dispatchEvent
method, though it may be called multiple times during that phase if
necessary. If called multiple times, the final invocation takes
precedence.

Parameters

namespaceURI of type
DOMString

Specifies the namespace URI
associated with this event, or null if the application
wish to have no namespace.

Specifies the previous namespaceURI of the related
Node. This value may be null.

prevNodeName of type
DOMString

Specifies the previous nodeName of the related
Node.

No Return Value

No Exceptions

The mutation name event types are listed below. For a full
description of the semantics associated with these event types,
refer to the Complete list of event
types. A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "MutationNameEvents" and "3.0"
(respectively) to determine whether or not the MutationNameEvent
is supported by the implementation. In order to fully support this
module, an implementation must also support the
"MutationEvents" feature defined in this specification
and the "Core" feature defined in the DOM Level 3 Core
specification [DOM Level 3 Core]. For additional
information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core].

1.7.6.
Basic event types

A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "BasicEvents" and
"3.0" (respectively) to determine whether or not the
basic 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. For
additional information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core].

The basic event types are listed below. For a full description
of the semantics associated with these event types, refer to the Complete list of
event types.

The event types {"http://www.w3.org/2001/xml-events",
"resize"} and {"http://www.w3.org/2001/xml-events",
"scroll"} implement the UIEvent interface.
All other HTML event types implement at least the basic Event interface.
However, they may be generated from a user interface; in that case,
the event objects also implements the UIEvent interface and
UIEvent.view is
in use.

1.7.7.
HTML Events

The HTML event module is composed of events listed in [HTML 4.01]
and additional events which are supported in DOM Level 0 browsers.
It refines the semantics and scope of the basic event types and
provides two new event types. This event module is only applicable
if the Document supports the [DOM Level 2
HTML] specification. Use Node.isSupported(feature,
version) with the parameter values "HTML" and "2.0"
(respectively) to determine whether or not the
Document node supported the HTML module.

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
"BasicEvents" feature defined in this specification
and the "HTML" feature defined in [DOM Level 2
HTML]. For additional information about conformance, please see the DOM Level 3 Core
specification [DOM Level 3 Core]. The DOM Level 3
HTML Events module is built on top of the DOM Level 2 HTML Events
[DOM
Level 2 Events] module, i.e. a DOM Level 3 HTML Events
implementation where hasFeature("HTMLEvents", "3.0")
returns true must also return true when
the version number is "2.0",
"" or, null.

Event type

Description

Target node

"http://www.w3.org/2001/xml-events", "load"

The DOM implementation
finishes loading all content within the BODY element, all frames
within a FRAMESET, or any resource linked from the document.

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

HTMLBodyElement, HTMLFrameSetElement

"http://www.w3.org/2001/xml-events", "abort"

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

HTMLObjectElement

"http://www.w3.org/2001/xml-events", "error"

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.

HTMLObjectElement, HTMLBodyElement,
HTMLFrameSetElement

"http://www.w3.org/2001/xml-events", "select"

A user selects some text
in a text field either via the user interface or via attributes
defined in [DOM Level 2 HTML]. This event is
valid for INPUT and TEXTAREA elements.

HTMLInputElement, HTMLTextAreaElement

"http://www.w3.org/2001/xml-events", "change"

A control loses the input
focus and its value has been modified since gaining focus. This
event can occur either via a user interface manipulation or the
focus() methods and the attributes defined in [DOM
Level 2 HTML]. This event is valid for INPUT, SELECT, and
TEXTAREA element.

HTMLInputElement, HTMLSelectElement,
HTMLTextAreaElement

"http://www.w3.org/2001/xml-events", "submit"

A form is submitted either
via a button. This event only applies to the FORM element. Note
that the HTMLFormElement.submit() method defined in
[DOM
Level 2 HTML] does not fire this event type.

HTMLFormElement

"http://www.w3.org/2001/xml-events", "reset"

A form is reset either via
a button, or the HTMLFormElement.reset() method
defined in [DOM Level 2 HTML]. This event only
applies to the FORM element.

HTMLFormElement

"http://www.w3.org/2001/xml-events", "resize"

A document view is
resized.

HTMLDocument

"http://www.w3.org/2001/xml-events", "scroll"

A document view is
scrolled.

HTMLDocument

The following new event types are defined:

Event type

Description

Bubbling phase

Cancelable

Target node

DOM interface

"http://www.w3.org/2001/xml-events", "focus"

An element receives focus
either via a pointing device, the focus() methods
defined in [DOM Level 2 HTML], or by tabbing
navigation. This event is only valid for the following elements: A,
AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

An element loses focus
either via a pointing device, the blur() methods
defined in [DOM Level 2 HTML], or by tabbing
navigation. This event is only valid for the following elements: A,
AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

The event types {"http://www.w3.org/2001/xml-events",
"focus"} and {"http://www.w3.org/2001/xml-events",
"blur"} may be generated from a user interface; in that
case, the event objects also implements the UIEvent interface and
UIEvent.view is
in use.

21 February
2003

Appendix A: Key identifiers for
keyboard events.

Editor:

Philippe Le Hégaret, W3C

A.1: Introduction

Each keyboard event references a key using a
DOMString key identifier. The set contained in this
appendix is based on the sets of keycodes from:

the interface java.awt.event.KeyEvent of the Java
2 Platform v1.4 [KeyEvent for Java];

While implementations are recommended to use the most relevant
identifier for a key independently of the platform or keyboard
layout mappings, DOM applications should not make assumption on the
ability of keyboard devices to generate them. When using keyboard
events, "consider using numbers and function keys (F4, F5,
and so on) instead of letters in shortcut-key combinaisons"
([DWW95]) given that most keyboard
layouts will provide keys for those.

"U+000000", "U+000001", ...,
"U+FFFFFF" are Unicode based key identifiers ([Unicode
3.0]). When a key cannot be mapped to Unicode, a specific
identifier is used (see also Guidelines
for defining key identifiers). In any case, no assumption
should be made between the sequence of keyboard events and the text
events. The following three examples illustrated the concept of
keyboard layout mappings and its relation with keyboard events.

The keystroke "U+000051" (Latin Capital Letter Q
key) will produce (on a PC/AT US keyboard using a US keyboard
layout mapping and without any modifier activated) the Unicode
character q (Latin Small Letter Q):

A.1.2: Dead keys

Keyboard input use dead keys for the input of composed character
sequences. Unlike the handwriting sequence, in which users type the
base character first, keyboard input require to enter a special
state when a dead key is pressed and emit the character(s) only
when one of a limited number of "legal" base character is
entered.

The dead keys are represented in the key identifiers set using
combining diacritical marks. The sequence of keystrokes "U+000302"
(Combining Circumflex Accent key) and "U+000045" (Latin Capital
Letter E key) will likely produce (on a PC/AT french keyboard using
a french mapping and without any modifier activated) the Unicode
character é (Latin Small Letter E With Acute) or the
composed Unicode character sequence e (Latin Small Letter E) and
000302 (Combining Circumflex Accent). In practice,
french keyboard input will generate the Unicode character é
instead of the composed Unicode character sequence, as shown in the
following example:

A.1.3: Input Method Editors

Also known as front end
processor, an input method editor (IME) is an
application that performs the conversion between keystrokes and
ideographs or other characters, usually by user-guided dictionary
lookup.

The IMEs function keys are not represented in this set. As an
example, receiving an keydown for the "Accept" key identifier does
not necessarily implies that the text currently selected in the IME
is being accepted. It only indicates that a keystroke happened,
disconnected from the IME Accept functionality. Depending on the
device in use, the IME Accept functionality can be obtain using the
Accept key or the Return key. Keyboard events cannot be used to
determine the current state of the input method editor.

Keyboard events correspond to the events generated by the input
device after the keyboard layout mapping but before the processing
of the input method editor.

The following example describes a possible sequence of keys to
generate the Unicode character し (Hiragana Letter SI) using
Japanese input methods. This assumes that the input method editor
is activated and in the Japanese-Romaji input mode. The keys
"Convert" and "Accept" may be replaced by
others depending on the input device in use and the configuration
of the IME, e.g. it could be respectively "U+000020" (Space key)
and "Enter".

Note: This specification does not provide a
representation of the input method editor (IME) events, e.g.
representing the input context.

A.1.4: Guidelines for defining key
identifiers

Note: This section is informative.

The list of key identifiers contained in this appendix is not
exhaustive and input devices may have to define their own key
identifiers. Here is a algorithm to determine which key identifier
to use:

Determine a representation for the key by looking at the
keyboard layout mapping in use (and not the keyboard device in
use). This representation should be unique, as human friendly as
possible, platform independent, and consistent. For example, on
PC/AT US keyboards with a US mapping, the 'Q' key is mapped to the
key identifier "U+000051" (Latin Capital Letter Q key), the '1/!'
key is mapped to the key identifier "U+000031" (Digit One key), the
key '`/~' is mapped to the key identifier "U+000060" (Grave Accent
key), and the 'Enter' key is mapped to the key identifier
"Enter".

Find an appropriate mapping in the Unicode character set. There
might not always be an appropriate and obvious mapping: the Unicode
set contains characters and symbols, the key might generate
different characters depending on the operating system, ... In
general, unless the representation of the key can be mapped to a
unique Unicode character, it is better to create a new one.

If no appropriate mapping was found, create an key identifier
as human friendly as possible. As an example, the Enter key is
mapped to the key identifier "Enter" and not to "U+00000A" (Line
Feed), given that this key generates the character 00000A on Unix
operating systems and the characters 00000D and 00000A on Windows
operating systems.

A.2: Key identifiers set

Note: The keycodes Multiply,
Add, Substract, Decimal,
Separator, Divide, NumPad0,
NumPad1, NumPad2, NumPad3,
NumPad4, NumPad5, NumPad6,
NumPad7, NumPad8, and
NumPad9 are not part of this set. Use
KeyBoard.keyLocation to know if a key originated from
the numeric keypad.

"Accept"

The Accept (Commit) key.

"Again"

The Again key.

"AllCandidates"

The All Candidates key.

"Alphanumeric"

The Alphanumeric key.

"Alt"

The Alt (Menu) key.

"AltGraph"

The Alt-Graph key.

"Apps"

The Application key.

"Attn"

The ATTN key.

"BrowserBack"

The Browser Back key.

"BrowserFavorites"

The Browser Favorites key.

"BrowserForward"

The Browser Forward key.

"BrowserHome"

The Browser Home key.

"BrowserRefresh"

The Browser Refresh key.

"BrowserSearch"

The Browser Search key.

"BrowserStop"

The Browser Stop key.

"CapsLock"

The Caps Lock (Capital) key.

"Clear"

The Clear key.

"CodeInput"

The Code Input key.

"Compose"

The Compose key.

"Control"

The Control (Ctrl) key.

"Crsel"

The Crsel key.

"Convert"

The Convert key.

"Copy"

The Copy key.

"Cut"

The Cut key.

"Down"

The Down Arrow key.

"End"

The End key.

"Enter"

The Enter key.

Note: This key identifier is also used for the Return
(Macintosh numpad) key.

"EraseEof"

The Erase EOF key.

"Execute"

The Execute key.

"Exsel"

The Exsel key.

"F1"

The F1 key.

"F2"

The F2 key.

"F3"

The F3 key.

"F4"

The F4 key.

"F5"

The F5 key.

"F6"

The F6 key.

"F7"

The F7 key.

"F8"

The F8 key.

"F9"

The F9 key.

"F10"

The F10 key.

"F11"

The F11 key.

"F12"

The F12 key.

"F13"

The F13 key.

"F14"

The F14 key.

"F15"

The F15 key.

"F16"

The F16 key.

"F17"

The F17 key.

"F18"

The F18 key.

"F19"

The F19 key.

"F20"

The F20 key.

"F21"

The F21 key.

"F22"

The F22 key.

"F23"

The F23 key.

"F24"

The F24 key.

"FinalMode"

The Final Mode (Final) key used on some asian keyboards.

"Find"

The Find key.

"FullWidth"

The Full-Width Characters key.

"HalfWidth"

The Half-Width Characters key.

"HangulMode"

The Hangul (Korean characters) Mode key.

"HanjaMode"

The Hanja (Korean characters) Mode key.

"Help"

The Help key.

"Hiragana"

The Hiragana (Japanese Kana characters) key.

"Home"

The Home key.

"Insert"

The Insert (Ins) key.

"JapaneseHiragana"

The Japanese-Hiragana key.

"JapaneseKatakana"

The Japanese-Katakana key.

"JapaneseRomaji"

The Japanese-Romaji key.

"JunjaMode"

The Junja Mode key.

"KanaMode"

The Kana Mode (Kana Lock) key.

"KanjiMode"

The Kanji (Japanese name for ideographic characters of Chinese
origin) Mode key.

Appendix B: Changes

B.1: Changes between
DOM Level 2 Events and DOM Level 3 Events

This new specification provides a better separation between the
DOM even flow, the event types, and the DOM interfaces.

B.1.1: Changes
to DOM Level 2 event flow

This new specification introduced two new concepts in the event
flow:

event groups: unlike DOM Level 2 Events,
stopPropagation does no longer stop the event
propagation entirely. It only stops it for a given event
group.

partial ordering of event listeners: within an event group,
event listeners are now ordered while ordering was unspecified in
DOM Level 2 Events.

B.1.2:
Changes to DOM Level 2 event types

Lots of clarifications have been made on the event types. The
conformance is now explicity defined against the event types, and
not only the interfaces required by the event types. Support for
namespaces and the feature "BasicEvents" have been
introduced.

The DOM Level 2 Event load event type can now be
dispatched to more [HTML 4.01] elements. blur
and focus have been clarified and restricted to [HTML
4.01] applications only.

This function has no return value.
The namespaceURI parameter is a String.
The type parameter is a String.
The listener parameter is an object that implements the
EventListener interface.
The useCapture parameter is a Boolean.
The evtGroup parameter is an object that implements the
EventListenerGroup interface.

This function has no return value.
The namespaceURI parameter is a String.
The type parameter is a String.
The listener parameter is an object that implements the
EventListener interface.
The useCapture parameter is a Boolean.
The evtGroup parameter is an object that implements the
EventListenerGroup interface.

willTriggerNS(namespaceURI, type)

This function returns a Boolean.
The namespaceURI parameter is a String.
The type parameter is a String.

hasEventListenerNS(namespaceURI, type)

This function returns a Boolean.
The namespaceURI parameter is a String.
The type parameter is a String.

EventListener function:

This function has no return value. The parameter is an object
that implements the Event interface.

Objects that implement the EventListenerGroup
interface:

Functions of objects that implement the
EventListenerGroup interface:

isSameEventListenerGroup(other)

This function returns a Boolean.
The other parameter is an object that implements the
EventListenerGroup interface.

Properties of the EventException Constructor
function:

EventException.UNSPECIFIED_EVENT_TYPE_ERR

The value of the constant
EventException.UNSPECIFIED_EVENT_TYPE_ERR is 0.

EventException.DISPATCH_REQUEST_ERR

The value of the constant
EventException.DISPATCH_REQUEST_ERR is 1.

Objects that implement the EventException
interface:

Properties of objects that implement the EventException
interface:

code

This property is a Number.

Objects that implement the DocumentEvent interface:

Functions of objects that implement the DocumentEvent
interface:

createEvent(eventType)

This function returns an object that implements the
Event interface.
The eventType parameter is a String.
This function can raise an object that implements the
DOMException interface.

createEventListenerGroup()

This function returns an object that implements the
EventListenerGroup interface.

canDispatch(namespaceURI, type)

This function returns a Boolean.
The namespaceURI parameter is a String.
The type parameter is a String.

Objects that implement the CustomEvent interface:

Objects that implement the CustomEvent interface have
all properties and functions of the Event interface as well
as the properties and functions defined below.

Functions of objects that implement the CustomEvent
interface:

setCurrentTarget(target)

This function has no return value.
The target parameter is an object that implements the
EventTarget interface.

setEventPhase(phase)

This function has no return value.
The phase parameter is a Number.

setCurrentEventListenerGroup(evtGroup)

This function has no return value.
The evtGroup parameter is an object that implements the
EventListenerGroup interface.

isImmediatePropagationStopped()

This function returns a Boolean.

Objects that implement the UIEvent interface:

Objects that implement the UIEvent interface have all
properties and functions of the Event interface as well as
the properties and functions defined below.

Properties of objects that implement the UIEvent
interface:

view

This read-only property is an object that implements the
AbstractView interface.

detail

This read-only property is a Number.

Functions of objects that implement the UIEvent
interface:

initUIEvent(typeArg, canBubbleArg, cancelableArg, viewArg,
detailArg)

This function has no return value.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The detailArg parameter is a Number.

This function has no return value.
The namespaceURI parameter is a String.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The detailArg parameter is a Number.

Objects that implement the TextEvent interface:

Objects that implement the TextEvent interface have all
properties and functions of the UIEvent interface as well as
the properties and functions defined below.

Properties of objects that implement the TextEvent
interface:

data

This read-only property is a String.

Functions of objects that implement the TextEvent
interface:

initTextEvent(typeArg, canBubbleArg, cancelableArg, viewArg,
dataArg)

This function has no return value.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The dataArg parameter is a String.

This function has no return value.
The namespaceURI parameter is a String.
The type parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The dataArg parameter is a String.

Objects that implement the MouseEvent interface:

Objects that implement the MouseEvent interface have all
properties and functions of the UIEvent interface as well as
the properties and functions defined below.

Properties of objects that implement the MouseEvent
interface:

screenX

This read-only property is a Number.

screenY

This read-only property is a Number.

clientX

This read-only property is a Number.

clientY

This read-only property is a Number.

ctrlKey

This read-only property is a Boolean.

shiftKey

This read-only property is a Boolean.

altKey

This read-only property is a Boolean.

metaKey

This read-only property is a Boolean.

button

This read-only property is a Number.

relatedTarget

This read-only property is an object that implements the
EventTarget interface.

This function has no return value.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The detailArg parameter is a Number.
The screenXArg parameter is a Number.
The screenYArg parameter is a Number.
The clientXArg parameter is a Number.
The clientYArg parameter is a Number.
The ctrlKeyArg parameter is a Boolean.
The altKeyArg parameter is a Boolean.
The shiftKeyArg parameter is a Boolean.
The metaKeyArg parameter is a Boolean.
The buttonArg parameter is a Number.
The relatedTargetArg parameter is an object that implements
the EventTarget interface.

This function has no return value.
The namespaceURI parameter is a String.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The detailArg parameter is a Number.
The screenXArg parameter is a Number.
The screenYArg parameter is a Number.
The clientXArg parameter is a Number.
The clientYArg parameter is a Number.
The ctrlKeyArg parameter is a Boolean.
The altKeyArg parameter is a Boolean.
The shiftKeyArg parameter is a Boolean.
The metaKeyArg parameter is a Boolean.
The buttonArg parameter is a Number.
The relatedTargetArg parameter is an object that implements
the EventTarget interface.
The altGraphKeyArg parameter is a Boolean.

Properties of the KeyboardEvent Constructor
function:

KeyboardEvent.DOM_KEY_LOCATION_STANDARD

The value of the constant
KeyboardEvent.DOM_KEY_LOCATION_STANDARD is 0x00.

KeyboardEvent.DOM_KEY_LOCATION_LEFT

The value of the constant
KeyboardEvent.DOM_KEY_LOCATION_LEFT is 0x01.

KeyboardEvent.DOM_KEY_LOCATION_RIGHT

The value of the constant
KeyboardEvent.DOM_KEY_LOCATION_RIGHT is 0x02.

KeyboardEvent.DOM_KEY_LOCATION_NUMPAD

The value of the constant
KeyboardEvent.DOM_KEY_LOCATION_NUMPAD is 0x03.

KeyboardEvent.DOM_KEY_LOCATION_UNKNOWN

The value of the constant
KeyboardEvent.DOM_KEY_LOCATION_UNKNOWN is 0x04.

Objects that implement the KeyboardEvent interface:

Objects that implement the KeyboardEvent interface have
all properties and functions of the UIEvent interface as
well as the properties and functions defined below.

This function has no return value.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The keyIdentifierArg parameter is a String.
The keyLocationArg parameter is a Number.
The ctrlKeyArg parameter is a Boolean.
The shiftKeyArg parameter is a Boolean.
The altKeyArg parameter is a Boolean.
The metaKeyArg parameter is a Boolean.
The altGraphKeyArg parameter is a Boolean.

This function has no return value.
The namespaceURI parameter is a String.
The type parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The viewArg parameter is an object that implements the
AbstractView interface.
The keyIdentifierArg parameter is a String.
The keyLocationArg parameter is a Number.
The ctrlKeyArg parameter is a Boolean.
The shiftKeyArg parameter is a Boolean.
The altKeyArg parameter is a Boolean.
The metaKeyArg parameter is a Boolean.
The altGraphKeyArg parameter is a Boolean.

Properties of the MutationEvent Constructor
function:

MutationEvent.MODIFICATION

The value of the constant MutationEvent.MODIFICATION is
1.

MutationEvent.ADDITION

The value of the constant MutationEvent.ADDITION is
2.

MutationEvent.REMOVAL

The value of the constant MutationEvent.REMOVAL is
3.

Objects that implement the MutationEvent interface:

Objects that implement the MutationEvent interface have
all properties and functions of the Event interface as well
as the properties and functions defined below.

Properties of objects that implement the MutationEvent
interface:

relatedNode

This read-only property is an object that implements the
Node interface.

This function has no return value.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The relatedNodeArg parameter is an object that implements
the Node interface.
The prevValueArg parameter is a String.
The newValueArg parameter is a String.
The attrNameArg parameter is a String.
The attrChangeArg parameter is a Number.

This function has no return value.
The namespaceURI parameter is a String.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The relatedNodeArg parameter is an object that implements
the Node interface.
The prevValueArg parameter is a String.
The newValueArg parameter is a String.
The attrNameArg parameter is a String.
The attrChangeArg parameter is a Number.

Objects that implement the MutationNameEvent
interface:

Objects that implement the MutationNameEvent interface
have all properties and functions of the MutationEvent
interface as well as the properties and functions defined
below.

This function has no return value.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The relatedNodeArg parameter is an object that implements
the Node interface.
The prevNamespaceURI parameter is a String.
The prevNodeName parameter is a String.

This function has no return value.
The namespaceURI parameter is a String.
The typeArg parameter is a String.
The canBubbleArg parameter is a Boolean.
The cancelableArg parameter is a Boolean.
The relatedNodeArg parameter is an object that implements
the Node interface.
The prevNamespaceURI parameter is a String.
The prevNodeName parameter is a String.

21 February
2003

Glossary

Editors:

Arnaud Le Hors, W3C

Robert S. Sutor, IBM Research (for DOM Level 1)

Several of the following term definitions have been borrowed or
modified from similar definitions in other W3C or standards
documents. See the links within the definitions for more
information.

There is an ordering, document order, defined on all the
nodes in the document corresponding to the order in which the first
character of the XML representation of each node occurs in the XML
representation of the document after expansion of general entities.
Thus, the document
element node will be the first node. Element nodes occur
before their children. Thus, document order orders element nodes in
order of the occurrence of their start-tag in the XML (after
expansion of entities). The attribute nodes of an element occur
after the element and before its children. The relative order of
attribute nodes is implementation-dependent.

The term "DOM Level 0" refers to a mix (not formally specified)
of HTML document functionalities offered by Netscape Navigator
version 3.0 and Microsoft Internet Explorer version 3.0. In some
cases, attributes or methods have been included for reasons of
backward compatibility with "DOM Level 0".

An event is the representation of some asynchronous occurrence
(such as a mouse click on the presentation of the element, or the
removal of child node from an element, or any of unthinkably many
other possibilities) that gets associated with an event target.

The description given to various information items (for
example, attribute values of various types, but not including the
StringType CDATA) after having been processed by the XML processor.
The process includes stripping leading and trailing white space,
and replacing multiple space characters by one. See the definition
of tokenized type.

A node is a well-formed XML node if it matches its
respective production in [XML 1.0], meets all well-formedness
constraints related to the production, if the entities which are
referenced within the node are also well-formed. See also the
definition for well-formed
XML documents in [XML 1.0].

HTML 4.01
Specification, D. Raggett, A. Le Hors, and I. Jacobs,
Editors. World Wide Web Consortium, 17 December 1997, revised 24
April 1998, revised 24 December 1999. This version of the HTML 4.01
Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224.
The latest
version of HTML 4 is available at
http://www.w3.org/TR/html4.

Namespaces in
XML, T. Bray, D. Hollander, and A. Layman, Editors.
World Wide Web Consortium, 14 January 1999. This version of the XML
Information Set Recommendation is
http://www.w3.org/TR/1999/REC-xml-names-19990114. The latest
version of Namespaces in XML is available at
http://www.w3.org/TR/REC-xml-names.

XForms
1.0, M. Dubinko, et al., Editors. World Wide Web
Consortium, November 2002. This version of the XForms 1.0
specification is http://www.w3.org/TR/2002/CR-xforms-20021112/. The
latest
version of XForms 1.0 is available at
http://www.w3.org/TR/xforms/.

XML
Events, S. McCarron, S. Pemberton, and T.V. Raman,
Editors. World Wide Web Consortium, February 2003. This version of
the XML Events specification is
http://www.w3.org/TR/2003/CR-xml-events-20030207. The latest version
of XML Events is available at
http://www.w3.org/TR/xml-events.