The DOM Level 3 Event Model is designed with two main goals. The first goal is the design of a generic event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event. Additionally, the specification will provide standard modules of events for user interface control and document mutation notifications, including defined contextual information for each of these event modules.
The second goal of the event model is to provide a common subset of the current event systems used in DOM Level 0 browsers. This is intended to foster interoperability of existing scripts and content. It is not expected that this goal will be met with full backwards compatibility. However, the specification attempts to achieve this when possible.
The following sections of the Event Model specification define both the specification for the DOM Event Model and a number of conformant event modules designed for use within the model. The Event Model consists of the two sections on event propagation and event listener registration and the Event interface.
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "Events" and "3.0" (respectively)
to determine whether or not the event module is supported by the
implementation. In order to fully support this module, an
implementation must also support the "Core" feature defined in the
DOM Level 3 Core specification [DOM Level 3 Core]. Please, refer to
additional information about conformance in the DOM Level 3 Core
specification [DOM
Level 3 Core].
Each event module describes its own feature string in the event module listing.
Event flow is the process through which the an event originates
from the DOM implementation and is passed into the Document Object
Model. The methods of event capture and event bubbling, along with
various event listener registration techniques, allow the event to
then be handled in a number of ways. It can be handled locally at
the EventTarget level or centrally from an EventTarget
higher in the document tree.
Each event has an EventTarget
toward which the event is directed by the DOM implementation. This
EventTarget is
specified in the Event's
target attribute. When the event reaches the target,
any event listeners registered on the EventTarget are
triggered. Although all EventListeners
on the EventTarget are
guaranteed to be triggered by any event which is received by that
EventTarget, no specification is made as to the order
in which they will receive the event with regards to the other EventListeners
on the EventTarget. If
neither event capture or event bubbling are in use for that
particular event, the event flow process will complete after all
listeners have been triggered. If event capture or event bubbling
is in use, the event flow will be modified as described in the
sections below.
Any exceptions thrown inside an EventListener
will not stop propagation of the event. It will continue processing
any additional EventListener
in the described manner.
It is expected that actions taken by EventListeners
may cause additional events to fire. Additional events should be
handled in a synchronous manner and may cause reentrancy into the
event model.
Event capture is the process by which an EventListener
registered on an ancestor of the event's
target can intercept events of a given type before they are
received by the event's target. Capture operates from the top of
the tree, generally the Document, downward, making it
the symmetrical opposite of bubbling which is described below. The
chain of EventTargets from
the top of the tree to the event's target is determined before the
initial dispatch of the event. If modifications occur to the tree
during event processing, event flow will proceed based on the
initial state of the tree.
An EventListener
being registered on an EventTarget may
choose to have that EventListener
capture events by specifying the useCapture parameter
of the addEventListener method to be
true. Thereafter, when an event of the given type is
dispatched toward a descendant of the
capturing object, the event will trigger any capturing event
listeners of the appropriate type which exist in the direct line
between the top of the document and the event's target. This
downward propagation continues until the event's target is reached.
A capturing EventListener
will not be triggered by events dispatched directly to the EventTarget upon
which it is registered.
If the capturing EventListener
wishes to prevent further processing of the event from occurring it
may call the stopProgagation method of the Event interface. This
will prevent further dispatch of the event, although additional EventListeners
registered at the same hierarchy level will still receive the
event. Once an event's stopPropagation method has been
called, further calls to that method have no additional effect. If
no additional capturers exist and stopPropagation has
not been called, the event triggers the appropriate EventListeners
on the target itself.
Although event capture is similar to the delegation based event
model in which all interested parties register their listeners
directly on the target about which they wish to receive
notifications, it is different in two important respects. First,
event capture only allows interception of events which are targeted
at descendants
of the capturing EventTarget. It
does not allow interception of events targeted to the capturer's ancestors, its siblings, or its
sibling's descendants. Secondly,
event capture is not specified for a single EventTarget, it
is specified for a specific type of event. Once specified, event
capture intercepts all events of the specified type targeted toward
any of the capturer's descendants.
Events which are designated as bubbling will initially proceed
with the same event flow as non-bubbling events. The event is
dispatched to its target EventTarget and
any event listeners found there are triggered. Bubbling events will
then trigger any additional event listeners found by following the
EventTarget's
parent chain upward, checking for any event listeners registered on
each successive EventTarget. This
upward propagation will continue up to and including the
Document. EventListeners
registered as capturers will not be triggered during this phase.
The chain of EventTargets from
the event target to the top of the tree is determined before the
initial dispatch of the event. If modifications occur to the tree
during event processing, event flow will proceed based on the
initial state of the tree.
Any event handler may choose to prevent further event
propagation by calling the stopPropagation method of
the Event
interface. If any EventListener
calls this method, all additional EventListeners
on the current EventTarget will
be triggered but bubbling will cease at that level. Only one call
to stopPropagation is required to prevent further
bubbling.
Some events are specified as cancelable. For these events, the DOM implementation generally has a default action associated with the event. An example of this is a hyperlink in a web browser. When the user clicks on the hyperlink the default action is generally to active that hyperlink. Before processing these events, the implementation must check for event listeners registered to receive the event and dispatch the event to those listeners. These listeners then have the option of canceling the implementation's default action or allowing the default action to proceed. In the case of the hyperlink in the browser, canceling the action would have the result of not activating the hyperlink.
Cancelation is accomplished by calling the Event's
preventDefault method. If one or more EventListeners
call preventDefault during any phase of event flow the
default action will be canceled.
Different implementations will specify their own default actions, if any, associated with each event. The DOM does not attempt to specify these actions.
The EventTarget interface is implemented by all
Nodes in an implementation which supports the DOM
Event Model. Therefore, this interface can be obtained by using
binding-specific casting methods on an instance of the
Node interface. The interface allows registration and
removal of EventListeners
on an EventTarget and dispatch of events to that
EventTarget.
// Introduced in DOM Level 2:
interface EventTarget {
void addEventListener(in DOMString type,
in EventListener listener,
in boolean useCapture);
void removeEventListener(in DOMString type,
in EventListener listener,
in boolean useCapture);
boolean dispatchEvent(in Event evt)
raises(EventException);
// Introduced in DOM Level 3:
readonly attribute EventListenerList eventListeners;
};
eventListeners of type
EventListenerList,
readonly, introduced in DOM Level 3EventListenerList
that contains all event listeners on this target.addEventListenerEventListener
is added to an EventTarget while it is processing an
event, the EventListener
will not be triggered by the current actions but may be triggered
during a later stage of event flow, such as the bubbling
phase.EventListeners
are registered on the same EventTarget with the same
parameters the duplicate instances are discarded. They do not cause
the EventListener
to be called twice and since they are discarded they do not need to
be removed with the removeEventListener method.
type of type
DOMStringlistener of type EventListenerlistener parameter takes an interface
implemented by the user which contains the methods to be called
when the event occurs.useCapture of type
booleanuseCapture indicates that the user wishes
to initiate capture. After initiating capture, all events of the
specified type will be dispatched to the registered EventListener
before being dispatched to any EventTargets beneath
them in the tree. Events which are bubbling upward through the tree
will not trigger an EventListener
designated to use capture.dispatchEventEventTarget on which dispatchEvent
is called.
evt of type Event|
|
The return value of |
removeEventListenerEventListener
is removed from an EventTarget while it is processing
an event, it will not be triggered by the current actions. EventListeners
can never be invoked after being removed.removeEventListener with arguments which do
not identify any currently registered EventListener
on the EventTarget has no effect.
type of type
DOMStringEventListener
being removed.listener of type EventListenerEventListener
parameter indicates the EventListener to be
removed.useCapture of type
booleanEventListener
being removed was registered as a capturing listener or not. If a
listener was registered twice, one with capture and one without,
each must be removed separately. Removal of a capturing listener
does not affect a non-capturing version of the same listener, and
vice versa.The EventListener interface is the primary method
for handling events. Users implement the EventListener
interface and register their listener on an EventTarget using
the AddEventListener method. The users should also
remove their EventListener from its EventTarget
after they have completed using the listener.
When a Node is copied using the
cloneNode method the EventListeners
attached to the source Node are not attached to the
copied Node. If the user wishes the same
EventListeners to be added to the newly created copy
the user must add them manually.
When a Node is adopted using the
adoptNode method the EventListeners
attached to the source Node stay attached to the
adopted Node.
// Introduced in DOM Level 2:
interface EventListener {
void handleEvent(in Event evt);
};
handleEventEventListener interface was
registered.
The EventListenerList interface provides the
abstraction of an ordered collection of event listeners, without
defining or constraining how this collection is implemented.
EventListenerList objects in the DOM are live.
The items in the EventListenerList are accessible
via an integral index, starting from 0.
// Introduced in DOM Level 3:
interface EventListenerList {
EventListener item(in unsigned long index);
readonly attribute unsigned long length;
};
length of type
unsigned long, readonlylength-1
inclusive.itemindexth item in the
collection. If index is greater than or equal to the
number of event listeners in the list, this returns
null.
index of type
unsigned long|
The event listener at the |
EventListener grouping is intended to allow groups of EventListeners
to be registered which will each have independent event flow within
them which is not affected by changes to event flow in any other
group. This may be used to control events separately in multiple
views on a document. It may also be used to develop an application
which uses events without the problem of possible interference by
other applications running within the same document.
The new interfaces added for EventListener grouping should not
interfere with the interfaces established in the Level 2 DOM Events
module. For purposes of interoperability between the Level 2 DOM
Event Model and the new interfaces added in Level 3, the
implementation can be assumed to define a default EventGroup. This
default EventGroup is
implicitly used in the registration of all EventListeners
registered via methods which do not specify an EventGroup
(addEventListener,
removeEventListener).
The EventGroup interface functions primarily as a placeholder for separating the event flows when there are multiple groups of listeners for a DOM tree.
EventListeners
can be registered without an EventGroup using the
existing EventTarget
interface, or with an associated EventGroup using the
new EventTargetGroup
interface. When an event is dispatched, it is dispatched
independently to each EventGroup. In particular, the
stopPropagation method of the Event interface only
stops propagation within an EventListener's
associated EventGroup.
// Introduced in DOM Level 3:
interface EventGroup {
boolean isSameEventGroup(in EventGroup other);
};
isSameEventGroupEventGroup is the same as the EventGroup
upon which the method is called.
other of type EventGroupEventGroup with which to check equality.|
|
Returns true if the |
The EventTargetGroup interface is implemented by the same set of
objects that implement the EventTarget
interface, namely all EventTargets in
in implementation which supports the Event model and the EventGroup
extension.
// Introduced in DOM Level 3:
interface EventTargetGroup {
void addEventListener(in DOMString type,
in EventListener listener,
in boolean useCapture,
in EventGroup evtGroup);
void removeEventListener(in DOMString type,
in EventListener listener,
in boolean useCapture,
in EventGroup evtGroup);
};
addEventListeneraddEventListener method of the EventTarget
interface, with the exception of the added eventGroup
parameter. The listener is registered with this EventGroup
associated.
type of type
DOMStringlistener of type EventListeneruseCapture of type
booleanevtGroup of type EventGroupEventGroup to
associate with the listener.removeEventListenerremoveEventListener method of the EventTarget
interface, with the exception of the added eventGroup
parameter. The listener registered with this EventGroup
associated is removed.
type of type
DOMStringlistener of type EventListeneruseCapture of type
booleanevtGroup of type EventGroupEventGroup to
associate with the listener.The DocumentEventGroup interface provides a
mechanism by which the user can create an EventGroup of a
type supported by the implementation. It is expected that the DocumentEvent
interface will be implemented on the same object which implements
the Documentinterface in an implementation which
supports the EventGroupextension.
// Introduced in DOM Level 3:
interface DocumentEventGroup {
EventGroup createEventGroup();
};
createEventGroup|
The newly created |
In HTML 4.0, event listeners were specified as attributes of an
element. As such, registration of a second event listener of the
same type would replace the first listener. The DOM Event Model
allows registration of multiple event listeners on a single EventTarget.
To achieve this, event listeners are no longer stored as attribute
values.
In order to achieve compatibility with HTML 4.0, implementors
may view the setting of attributes which represent event handlers
as the creation and registration of an EventListener
on the EventTarget. The
value of useCapture defaults to false.
This EventListener
behaves in the same manner as any other EventListeners
which may be registered on the EventTarget. If
the attribute representing the event listener is changed, this may
be viewed as the removal of the previously registered EventListener
and the registration of a new one. No technique is provided to
allow HTML 4.0 event listeners access to the context information
defined for each event.
The Event interface is used to provide contextual
information about an event to the handler processing the event. An
object which implements the Event interface is
generally passed as the first parameter to an event handler. More
specific context information is passed to event handlers by
deriving additional interfaces from Event which
contain information directly relating to the type of event they
accompany. These derived interfaces are also implemented by the
object passed to the event listener.
// Introduced in DOM Level 2:
interface Event {
// PhaseType
const unsigned short CAPTURING_PHASE = 1;
const unsigned short AT_TARGET = 2;
const unsigned short BUBBLING_PHASE = 3;
readonly attribute DOMString type;
readonly attribute EventTarget target;
readonly attribute EventTarget currentTarget;
readonly attribute unsigned short eventPhase;
readonly attribute boolean bubbles;
readonly attribute boolean cancelable;
readonly attribute DOMTimeStamp timeStamp;
void stopPropagation();
void preventDefault();
void initEvent(in DOMString eventTypeArg,
in boolean canBubbleArg,
in boolean cancelableArg);
};
An integer indicating which phase of event flow is being processed.
AT_TARGETEventTarget.BUBBLING_PHASECAPTURING_PHASEbubbles of type
boolean, readonlycancelable of type
boolean, readonlycurrentTarget of type
EventTarget,
readonlyEventTarget whose
EventListeners
are currently being processed. This is particularly useful during
capturing and bubbling.eventPhase of type
unsigned short, readonlytarget of type EventTarget,
readonlyEventTarget to
which the event was originally dispatched.timeStamp of type
DOMTimeStamp, readonlytimeStamp may be not available for all events. When
not available, a value of 0 will be returned. Examples of epoch
time are the time of the system start or 0:0:0 UTC 1st January
1970.type of type DOMString,
readonlyinitEventinitEvent method is used to
initialize the value of an Event created through the
DocumentEvent
interface. This method may only be called before the
Event has been dispatched via the
dispatchEvent method, though it may be called multiple
times during that phase if necessary. If called multiple times the
final invocation takes precedence. If called from a subclass of
Event interface only the values specified in the
initEvent method are modified, all other attributes
are left unchanged.
eventTypeArg of type
DOMStringcanBubbleArg of type
booleancancelableArg of type
booleanpreventDefaultpreventDefault method is used to signify that the
event is to be canceled, meaning any default action normally taken
by the implementation as a result of the event will not occur. If,
during any stage of event flow, the preventDefault
method is called the event is canceled. Any default action
associated with the event will not occur. Calling this method for a
non-cancelable event has no effect. Once
preventDefault has been called it will remain in
effect throughout the remainder of the event's propagation. This
method may be used during any stage of event flow.
stopPropagationstopPropagation method is used
prevent further propagation of an event during event flow. If this
method is called by any EventListener
the event will cease propagating through the tree. The event will
complete dispatch to all listeners on the current EventTarget
before event flow stops. This method may be used during any stage
of event flow.
Event operations may throw an EventException
as specified in their method descriptions.
// Introduced in DOM Level 2:
exception EventException {
unsigned short code;
};
// EventExceptionCode
const unsigned short UNSPECIFIED_EVENT_TYPE_ERR = 0;
An integer indicating the type of error generated.
UNSPECIFIED_EVENT_TYPE_ERREvent's type was not
specified by initializing the event before the method was called.
Specification of the Event's type as null or an empty
string will also trigger this exception.The DocumentEvent interface provides a mechanism by
which the user can create an Event of a type supported by the
implementation. It is expected that the DocumentEvent
interface will be implemented on the same object which implements
the Document interface in an implementation which
supports the Event model.
// Introduced in DOM Level 2:
interface DocumentEvent {
Event createEvent(in DOMString eventType)
raises(DOMException);
};
createEventeventType of type
DOMStringeventType parameter specifies the type of Event interface to
be created. If the Event interface
specified is supported by the implementation this method will
return a new Event of the interface
type requested. If the Event is to be
dispatched via the dispatchEvent method the
appropriate event init method must be called after creation in
order to initialize the Event's values. As an
example, a user wishing to synthesize some kind of UIEvent would call
createEvent with the parameter "UIEvents". The
initUIEvent method could then be called on the newly
created UIEvent to set the
specific type of UIEvent to be dispatched and set its context
information.createEvent method is used in creating Events when it is
either inconvenient or unnecessary for the user to create an Event themselves. In
cases where the implementation provided Event is insufficient,
users may supply their own Event implementations
for use with the dispatchEvent method.|
|
NOT_SUPPORTED_ERR: Raised if the implementation does not support
the type of |
The DOM Level 2 Event Model allows a DOM implementation to support multiple modules of events. The model has been designed to allow addition of new event modules as is required. The DOM will not attempt to define all possible events. For purposes of interoperability, the DOM will define a module of user interface events including lower level device dependent events, a module of UI logical events, and a module of document mutation events. Any new event types defined by third parties must not begin with any upper, lower, or mixed case version of the string "DOM". This prefix is reserved for future DOM event modules. It is also strongly recommended that third parties adding their own events use their own prefix to avoid confusion and lessen the probability of conflicts with other new events.
The User Interface event module is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers.
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "UIEvents" and "3.0" (respectively)
to determine whether or not the User Interface event module is
supported by the implementation. In order to fully support this
module, an implementation must also support the "Events" feature
defined in this specification and the "Views" feature defined in
the DOM Level 2 Views specification [DOM Level 2 Views]. Please, refer to
additional information about conformance in the DOM Level 3 Core
specification [DOM
Level 3 Core].
Note: To create an instance of the UIEvent interface,
use the feature string "UIEvents" as the value of the input
parameter used with the createEvent method of the DocumentEvent
interface.
The UIEvent interface provides specific contextual
information associated with User Interface events.
// Introduced in DOM Level 2:
interface UIEvent : Event {
readonly attribute views::AbstractView view;
readonly attribute long detail;
void initUIEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in views::AbstractView viewArg,
in long detailArg);
};
initUIEventinitUIEvent method is used to
initialize the value of a UIEvent created through the
DocumentEvent
interface. This method may only be called before the
UIEvent has been dispatched via the
dispatchEvent method, though it may be called multiple
times during that phase if necessary. If called multiple times, the
final invocation takes precedence.
typeArg of type
DOMStringcanBubbleArg of type
booleancancelableArg of type
booleanviewArg of type
views::AbstractViewEvent's
AbstractView.detailArg of type
longEvent's detail.The different types of such events that can occur are:
EventTarget
receives focus, for instance via a pointing device being moved onto
an element or by tabbing navigation to the element. Unlike the HTML
event focus, DOMFocusIn can be applied to any focusable EventTarget, not
just FORM controls.
EventTarget loses
focus, for instance via a pointing device being moved out of an
element or by tabbing navigation out of the element. Unlike the
HTML event blur, DOMFocusOut can be applied to any focusable EventTarget, not
just FORM controls.
The Mouse event module is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers. This event module is specifically designed for use with mouse input devices.
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "MouseEvents" and "3.0"
(respectively) to determine whether or not the Mouse event module
is supported by the implementation. In order to fully support this
module, an implementation must also support the "UIEvents" feature
defined in this specification. Please, refer to additional
information about conformance in the DOM Level 3 Core specification
[DOM Level 3
Core].
Note: To create an instance of the MouseEvent
interface, use the feature string "MouseEvents" as the value of the
input parameter used with the createEvent method of
the DocumentEvent
interface.
The MouseEvent interface provides specific
contextual information associated with Mouse events.
The detail attribute inherited from UIEvent indicates the
number of times a mouse button has been pressed and released over
the same screen location during a user action. The attribute value
is 1 when the user begins this action and increments by 1 for each
full sequence of pressing and releasing. If the user moves the
mouse between the mousedown and mouseup the value will be set to 0,
indicating that no click is occurring.
In the case of nested elements mouse events are always targeted at the most deeply nested element. Ancestors of the targeted element may use bubbling to obtain notification of mouse events which occur within its descendent elements.
// Introduced in DOM Level 2:
interface MouseEvent : UIEvent {
readonly attribute long screenX;
readonly attribute long screenY;
readonly attribute long clientX;
readonly attribute long clientY;
readonly attribute boolean ctrlKey;
readonly attribute boolean shiftKey;
readonly attribute boolean altKey;
readonly attribute boolean metaKey;
readonly attribute unsigned short button;
readonly attribute EventTarget relatedTarget;
void initMouseEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in views::AbstractView viewArg,
in long detailArg,
in long screenXArg,
in long screenYArg,
in long clientXArg,
in long clientYArg,
in boolean ctrlKeyArg,
in boolean altKeyArg,
in boolean shiftKeyArg,
in boolean metaKeyArg,
in unsigned short buttonArg,
in EventTarget relatedTargetArg);
};
altKey of type
boolean, readonlybutton of type
unsigned short, readonlybutton is used to indicate which mouse
button changed state. The values for button range from
zero to indicate the left button of the mouse, one to indicate the
middle button if present, and two to indicate the right button. For
mice configured for left handed use in which the button actions are
reversed the values are instead read from right to left.clientX of type
long, readonlyclientY of type
long, readonlyctrlKey of type
boolean, readonlymetaKey of type
boolean, readonlyrelatedTarget of type
EventTarget,
readonlyEventTarget
related to a UI event. Currently this attribute is used with the
mouseover event to indicate the EventTarget which
the pointing device exited and with the mouseout event to indicate
the EventTarget which
the pointing device entered.screenX of type
long, readonlyscreenY of type
long, readonlyshiftKey of type
boolean, readonlyinitMouseEventinitMouseEvent method is used
to initialize the value of a MouseEvent created
through the DocumentEvent
interface. This method may only be called before the
MouseEvent has been dispatched via the
dispatchEvent method, though it may be called multiple
times during that phase if necessary. If called multiple times, the
final invocation takes precedence.
typeArg of type
DOMStringcanBubbleArg of type
booleancancelableArg of type
booleanviewArg of type
views::AbstractViewEvent's
AbstractView.detailArg of type
longEvent's mouse click
count.screenXArg of type
longEvent's screen x
coordinatescreenYArg of type
longEvent's screen y
coordinateclientXArg of type
longEvent's client x
coordinateclientYArg of type
longEvent's client y
coordinatectrlKeyArg of type
booleanEvent.altKeyArg of type
booleanEvent.shiftKeyArg of type
booleanEvent.metaKeyArg of type
booleanEvent.buttonArg of type
unsigned shortEvent's mouse
button.relatedTargetArg of type EventTargetEvent's related EventTarget.The different types of Mouse events that can occur are:
mousedown
mouseup
click
detail attribute incrementing with
each repetition. This event is valid for most elements.
EventTarget the
pointing device is exiting.EventTarget the
pointing device is entering.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 Mouse event module
is supported by the implementation. In order to fully support this
module, an implementation must also support the "UIEvents" feature
defined in this specification. Please, refer to additional
information about conformance in the DOM Level 3 Core specification
[DOM Level 3
Core].
Note: To create an instance of the TextEvent
interface, use the feature string "TextEvents" as the value of the
input parameter used with the createEvent method of
the DocumentEvent
interface.
The TextEvent interface provides specific
contextual information associated with Text Events.
// Introduced in DOM Level 3:
interface TextEvent : UIEvent {
// VirtualKeyCode
const unsigned long DOM_VK_UNDEFINED = 0x0;
const unsigned long DOM_VK_RIGHT_ALT = 0x01;
const unsigned long DOM_VK_LEFT_ALT = 0x02;
const unsigned long DOM_VK_LEFT_CONTROL = 0x03;
const unsigned long DOM_VK_RIGHT_CONTROL = 0x04;
const unsigned long DOM_VK_LEFT_SHIFT = 0x05;
const unsigned long DOM_VK_RIGHT_SHIFT = 0x06;
const unsigned long DOM_VK_LEFT_META = 0x07;
const unsigned long DOM_VK_RIGHT_META = 0x08;
const unsigned long DOM_VK_CAPS_LOCK = 0x09;
const unsigned long DOM_VK_DELETE = 0x0A;
const unsigned long DOM_VK_END = 0x0B;
const unsigned long DOM_VK_ENTER = 0x0C;
const unsigned long DOM_VK_ESCAPE = 0x0D;
const unsigned long DOM_VK_HOME = 0x0E;
const unsigned long DOM_VK_INSERT = 0x0F;
const unsigned long DOM_VK_NUM_LOCK = 0x10;
const unsigned long DOM_VK_PAUSE = 0x11;
const unsigned long DOM_VK_PRINTSCREEN = 0x12;
const unsigned long DOM_VK_SCROLL_LOCK = 0x13;
const unsigned long DOM_VK_LEFT = 0x14;
const unsigned long DOM_VK_RIGHT = 0x15;
const unsigned long DOM_VK_UP = 0x16;
const unsigned long DOM_VK_DOWN = 0x17;
const unsigned long DOM_VK_PAGE_DOWN = 0x18;
const unsigned long DOM_VK_PAGE_UP = 0x19;
const unsigned long DOM_VK_F1 = 0x1A;
const unsigned long DOM_VK_F2 = 0x1B;
const unsigned long DOM_VK_F3 = 0x1C;
const unsigned long DOM_VK_F4 = 0x1D;
const unsigned long DOM_VK_F5 = 0x1E;
const unsigned long DOM_VK_F6 = 0x1F;
const unsigned long DOM_VK_F7 = 0x20;
const unsigned long DOM_VK_F8 = 0x21;
const unsigned long DOM_VK_F9 = 0x22;
const unsigned long DOM_VK_F10 = 0x23;
const unsigned long DOM_VK_F11 = 0x24;
const unsigned long DOM_VK_F12 = 0x25;
const unsigned long DOM_VK_F13 = 0x26;
const unsigned long DOM_VK_F14 = 0x27;
const unsigned long DOM_VK_F15 = 0x28;
const unsigned long DOM_VK_F16 = 0x29;
const unsigned long DOM_VK_F17 = 0x2A;
const unsigned long DOM_VK_F18 = 0x2B;
const unsigned long DOM_VK_F19 = 0x2C;
const unsigned long DOM_VK_F20 = 0x2D;
const unsigned long DOM_VK_F21 = 0x2E;
const unsigned long DOM_VK_F22 = 0x2F;
const unsigned long DOM_VK_F23 = 0x30;
const unsigned long DOM_VK_F24 = 0x31;
attribute DOMString outputString;
attribute unsigned long keyVal;
attribute unsigned long virtKeyVal;
attribute boolean visibleOutputGenerated;
attribute boolean numPad;
boolean checkModifier(in unsigned long modifer);
void initTextEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in views::AbstractView viewArg,
in unsigned short detailArg,
in DOMString outputStringArg,
in unsigned long keyValArg,
in unsigned long virtKeyValArg,
in boolean visibleOutputGeneratedArg,
in boolean numPadArg);
void initModifier(in unsigned long modifier,
in boolean value);
};
An integer indicating which key was pressed.
DOM_VK_CAPS_LOCKDOM_VK_DELETEDOM_VK_DOWNDOM_VK_ENDDOM_VK_ENTERDOM_VK_ESCAPEDOM_VK_F1DOM_VK_F10DOM_VK_F11DOM_VK_F12DOM_VK_F13DOM_VK_F14DOM_VK_F15DOM_VK_F16DOM_VK_F17DOM_VK_F18DOM_VK_F19DOM_VK_F2DOM_VK_F20DOM_VK_F21DOM_VK_F22DOM_VK_F23DOM_VK_F24DOM_VK_F3DOM_VK_F4DOM_VK_F5DOM_VK_F6DOM_VK_F7DOM_VK_F8DOM_VK_F9DOM_VK_HOMEDOM_VK_INSERTDOM_VK_LEFTDOM_VK_LEFT_ALTDOM_VK_LEFT_CONTROLDOM_VK_LEFT_METADOM_VK_LEFT_SHIFTDOM_VK_NUM_LOCKDOM_VK_PAGE_DOWNDOM_VK_PAGE_UPDOM_VK_PAUSEDOM_VK_PRINTSCREENDOM_VK_RIGHTDOM_VK_RIGHT_ALTDOM_VK_RIGHT_CONTROLDOM_VK_RIGHT_METADOM_VK_RIGHT_SHIFTDOM_VK_SCROLL_LOCKDOM_VK_UNDEFINEDDOM_VK_UPkeyVal of type
unsigned longkeyVal holds the value of the Unicode
character associated with the depressed key. If the key has no
Unicode representation or no Unicode character is available the
value is 0..numPad of type
booleannumPad attribute indicates whether or not the
key event was generated on the number pad section of the keyboard.
If the number pad was used to generate the key event the value is
true, otherwise the value is false.outputString of type
DOMStringoutputString holds the value of the output
generated by the key event. This may be a single Unicode character
or it may be a string. It may also be null in the case where no
output was generated by the key event.virtKeyVal of type
unsigned longvirtKeyVal holds the virtual
key code associated with the depressed key. If the key has a
Unicode representation or no virtual code is available the value is
DOM_VK_UNDEFINED.visibleOutputGenerated
of type booleanvisibleOutputGenerated attribute indicates
whether the key event will normally cause visible output. If the
key event does not generate any visible output, such as the use of
a function key or the combination of certain modifier keys used in
conjunction with another key, then the value will be false. If
visible output is normally generated by the key event then the
value will be true.visibleOutputGenerated does not guarantee
the creation of a character. If a key event causing visible output
is cancelable it may be prevented from causing visible output. This
attribute is intended primarily to differentiate between keys
events which may or may not produce visible output depending on the
system state.checkModifiercheckModifier method is used
to check the status of a single modifier key associated with a
TextEvent. The identifier of the modifier in question
is passed into the checkModifier function. If the
modifier is triggered it will return true. If not, it will return
false.modifer of type
unsigned long|
|
The status of the modifier represented as a boolean. |
initModifierinitModifier method is used to
initialize the values of any modifiers associated with a
TextEvent created through the DocumentEvent
interface. This method may only be called before the
TextEvent has been dispatched via the dispatchEvent
method, though it may be called multiple times during that phase if
necessary. If called multiple times with the same
modifier property the final invocation takes
precedence. Unless explicitly give a value of true, all modifiers
have a value of false. This method has no effect if called after
the event has been dispatched.modifier of type
unsigned longvalue of type
booleaninitTextEventinitTextEvent method is used
to initialize the value of a TextEvent created through
the DocumentEvent
interface. This method may only be called before the
TextEvent has been dispatched via the dispatchEvent
method, though it may be called multiple times during that phase if
necessary. If called multiple times, the final invocation takes
precedence. This method has no effect if called after the event has
been dispatched.
typeArg of type
DOMStringcanBubbleArg of type
booleancancelableArg of type
booleanviewArg of type
views::AbstractViewTextEvent's
AbstractView.detailArg of type
unsigned shortoutputStringArg of type
DOMStringTextEvent's
outputString attributekeyValArg of type
unsigned longTextEvent's
keyValattributevirtKeyValArg of type
unsigned longTextEvent's
virtKeyValattributevisibleOutputGeneratedArg
of type booleanTextEvent's
visibleOutputGeneratedattributenumPadArg of type
booleanTextEvent's
numPadattributeThere are two major groups of key events. The first contains the
textEvent event. The textEvent event
indicates that text information has been entered, either in the
form of printable characters or non-printable text information such
as modifier keys. textEvent events are not necessarily
accompanied by the events of the second major groups of key events,
keydown and keyup.
detail attribute inherited from UIEvent is used to
indicated the number of keypresses which have occurred during key
repetition. If this information is not available this value should
be 0.
The keydown and keyup events comprise
the second group of key events. These events are fired to indicate
the physical motion of the keys on the character generation device.
Depending on the input system being used, textEvent
events may or may not be generated for each pair of
keydown and keyup events.
The mutation event module is designed to allow notification of any changes to the structure of a document, including attr and text modifications. It may be noted that none of the mutation events listed are designated as cancelable. This stems from the fact that it is very difficult to make use of existing DOM interfaces which cause document modifications if any change to the document might or might not take place due to cancelation of the related event. Although this is still a desired capability, it was decided that it would be better left until the addition of transactions into the DOM.
Many single modifications of the tree can cause multiple mutation events to be fired. Rather than attempt to specify the ordering of mutation events due to every possible modification of the tree, the ordering of these events is left to the implementation.
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "MutationEvents" and "3.0"
(respectively) to determine whether or not the Mutation event
module is supported by the implementation. In order to fully
support this module, an implementation must also support the
"Events" feature defined in this specification. Please, refer to
additional information about conformance in the DOM Level 3 Core
specification [DOM
Level 3 Core].
Note: To create an instance of the MutationEvent
interface, use the feature string "MutationEvents" as the value of
the input parameter used with the createEvent method
of the DocumentEvent
interface.
The MutationEvent interface provides specific
contextual information associated with Mutation events.
// Introduced in DOM Level 2:
interface MutationEvent : Event {
// attrChangeType
const unsigned short MODIFICATION = 1;
const unsigned short ADDITION = 2;
const unsigned short REMOVAL = 3;
readonly attribute Node relatedNode;
readonly attribute DOMString prevValue;
readonly attribute DOMString newValue;
readonly attribute DOMString attrName;
readonly attribute unsigned short attrChange;
void initMutationEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in Node relatedNodeArg,
in DOMString prevValueArg,
in DOMString newValueArg,
in DOMString attrNameArg,
in unsigned short attrChangeArg);
};
An integer indicating in which way the Attr was
changed.
ADDITIONAttr was just added.MODIFICATIONAttr was modified in place.REMOVALAttr was just removed.attrChange of type
unsigned short, readonlyattrChange indicates the type of change which
triggered the DOMAttrModified event. The values can be
MODIFICATION, ADDITION, or
REMOVAL.attrName of type
DOMString, readonlyattrName indicates the name of the changed
Attr node in a DOMAttrModified event.newValue of type
DOMString, readonlynewValue indicates the new value of the
Attr node in DOMAttrModified events, and of the
CharacterData node in DOMCharDataModified
events.prevValue of type
DOMString, readonlyprevValue indicates the previous value of the
Attr node in DOMAttrModified events, and of the
CharacterData node in DOMCharDataModified
events.relatedNode of type
Node, readonlyrelatedNode is used to identify a secondary node
related to a mutation event. For example, if a mutation event is
dispatched to a node indicating that its parent has changed, the
relatedNode is the changed parent. If an event is
instead 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.initMutationEventinitMutationEvent method is
used to initialize the value of a MutationEvent
created through the DocumentEvent
interface. This method may only be called before the
MutationEvent has been dispatched via the
dispatchEvent method, though it may be called multiple
times during that phase if necessary. If called multiple times, the
final invocation takes precedence.
typeArg of type
DOMStringcanBubbleArg of type
booleancancelableArg of type
booleanrelatedNodeArg of type
NodeEvent's related
Node.prevValueArg of type
DOMStringEvent's
prevValue attribute. This value may be null.newValueArg of type
DOMStringEvent's
newValue attribute. This value may be null.attrNameArg of type
DOMStringEvent's
attrName attribute. This value may be null.attrChangeArg of type
unsigned shortEvent's
attrChange attributeThe different types of Mutation events that can occur are:
Attr has been modified on a node.
The target of this event is the Node whose
Attr changed. The value of attrChange indicates
whether the Attr was modified, added, or removed. The
value of relatedNode indicates the Attr node whose
value has been affected. It is expected that string based
replacement of an Attr value will be viewed as a
modification of the Attr since its identity does not
change. Subsequently replacement of the Attr node with
a different Attr node is viewed as the removal of the
first Attr node and the addition of the second.
The HTML event module is composed of events listed in HTML 4.0 and additional events which are supported in DOM Level 0 browsers.
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "HTMLEvents" and "3.0"
(respectively) to determine whether or not the HTML event module is
supported by the implementation. In order to fully support this
module, an implementation must also support the "Events" feature
defined in this specification. Please, refer to additional
information about conformance in the DOM Level 3 Core specification
[DOM Level 3
Core].
Note: To create an instance of the Event interface for the
HTML event module, use the feature string "HTMLEvents" as the value
of the input parameter used with the createEvent
method of the DocumentEvent
interface.
The HTML events use the base DOM Event interface to pass contextual information.
The different types of such events that can occur are: