+Shortname: uievents-algo
+Level:
+Group:
+Status: DREAM
+Editor: No One
+Abstract:
+ This document provides a non-normative description of the DOM Event architecture.
+ It was previously part of the UI Events spec.
+
+
DOM Event Architecture
@@ -5,6 +18,10 @@
This section is non-normative. Refer to [[DOM]] for a normative description
of the DOM event architecture
+This information in this document was previously included in the UIEvents spec, but
+has been removed to this document so avoid confusion. As noted above, the proper
+definitions are part of the [[DOM]] specification.
+
Event dispatch and DOM event flow
This section gives a brief overview of the event dispatch mechanism
@@ -203,8 +220,7 @@ of the DOM event architecture
object derived from these objects using the algorithm below, all
{{KeyboardEvent}}, {{MouseEvent}}, and derived objects have
internal key modifier state which can be set and
- retrieved using the key modifier names
- described in the
+ retrieved using the key modifier names described in the
Modifier Keys table
in [[UIEvents-Key]].
@@ -226,3 +242,176 @@ of the DOM event architecture
to the corresponding value.
+
+
+
Glossary
+
+Some 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.
+
+: activation behavior
+:: The action taken when an event, typically initiated by users through
+ an input device, causes an element to fulfill a defined task. The task MAY
+ be defined for that element by the host language, or by
+ author-defined variables, or both. The default task for any given element
+ MAY be a generic action, or MAY be unique to that element. For example, the
+ activation behavior of an HTML or SVG <a> element is to
+ cause the user agent to traverse the link specified in the
+ href attribute, with the further optional parameter of
+ specifying the browsing context for the traversal (such as the current
+ window or tab, a named window, or a new window). The activation behavior of
+ an HTML <input> element with the type
+ attribute value submit is be to send the values of the form
+ elements to an author-defined IRI by the author-defined HTTP method.
+
+: activation trigger
+:: An event which is defined to initiate an activation behavior.
+
+: bubbling phase
+:: The process by which an event can be handled by one of the target's
+ ancestors after being handled by the event target. See the
+ description of the bubble phase in the context of event flow for more
+ details.
+
+: capture phase
+:: The process by which an event can be handled by one of the target's
+ ancestors before being handled by the event target. See the
+ description of the capture phase in the context
+ of event flow for more details.
+
+: current event target
+:: In an event flow, the current event target is the object associated with the
+ event handler that is currently being dispatched. This object MAY be
+ the event target itself or one of its ancestors. The current event
+ target changes as the event propagates from object to object through
+ the various phases of the event flow. The current event target is the
+ value of the {{Event/currentTarget}} attribute.
+
+: default action
+:: A default action is an OPTIONAL supplementary behavior that an
+ implementation MUST perform in combination with the dispatch of the event
+ object. Each event type definition, and each specification, defines the
+ default action for that event type, if it has one. An instance of an
+ event MAY have more than one default action under some circumstances,
+ such as when associated with an activation trigger. A default
+ action MAY be cancelled through the invocation of the
+ {{Event/preventDefault()}} method.
+
+: dispatch
+:: To create an event with attributes and methods appropriate to its type and
+ context, and propagate it through the DOM tree in the specified manner.
+ Interchangeable with the term fire, e.g., fire a
+ EVENT{click} event or dispatch a EVENT{load} event.
+
+: document
+:: An object instantiating the {{Document}} interface [[DOM-Level-3-Core]],
+ representing the entire HTML or XML text document. Conceptually, it is the
+ root of the document tree, and provides the primary access to the document's
+ data.
+
+: DOM application
+:: A DOM application is script or code, written by a content author or
+ automatically generated, which takes advantage of the interfaces, methods,
+ attributes, events, and other features described in this specification in
+ order to make dynamic or interactive content, such as Web applications,
+ exposed to users in a user agent.
+
+: event
+:: An event is the representation of some occurrence (such as a mouse click on
+ the presentation of an element, the removal of child node from an element,
+ or any number of other possibilities) which is associated with its event
+ target. Each event is an instantiation of one specific event
+ type.
+
+: event handler
+: event listener
+:: An object that implements the {{EventListener}} interface and provides an
+ {{EventListener/handleEvent()}} callback method. Event handlers are
+ language-specific. Event handlers are invoked in the context of a particular
+ object (the current event target) and are provided with the event
+ object itself.
+
+
+ In JavaScript, user-defined functions are considered to implement the
+ {{EventListener}} interface. Thus the event object will be provided as the
+ first parameter to the user-defined function when it is invoked.
+ Additionally, JavaScript objects can also implement the {{EventListener}}
+ interface when they define a {{EventListener/handleEvent()}} method.
+
+
+: event order
+:: The sequence in which events from the same event source or process occur,
+ using the same or related event interfaces. For example, in an environment
+ with a mouse, a track pad, and a keyboard, each of those input devices would
+ constitute a separate event source, and each would follow its own event
+ order. A EVENT{mousedown} event from the trackpad followed by a
+ EVENT{mouseup} event from the mouse would not result in a EVENT{click} event.
+
+
+ There can be interactions between different event orders. For example, a
+ EVENT{click} event might be modified by a concurrent EVENT{keydown} event
+ (e.g., via KEYCAP{Shift}+EVENT{click}). However, the event
+ orders of these different event sources would be distinct.
+
+ The event order of some interfaces are device-independent. For example, a
+ user might change focus using the KEYCAP{Tab} key, or by clicking the new
+ focused element with the mouse. The event order in such cases depends on
+ the state of the process, not on the state of the device that initiates the
+ state change.
+
+: event phase
+:: See phase.
+
+: event target
+:: The object to which an event is targeted using the event flow.
+ The event target is the value of the {{Event/target}} attribute.
+
+: fire
+:: A synonym for dispatch.
+
+: host language
+:: Any language which integrates the features of another language or API
+ specification, while normatively referencing the origin specification rather
+ than redefining those features, and extending those features only in ways
+ defined by the origin specification. An origin specification typically is
+ only intended to be implemented in the context of one or more host
+ languages, not as a standalone language. For example, XHTML, HTML, and SVG
+ are host languages for UI Events, and they integrate and extend the objects
+ and models defined in this specification.
+
+: phase
+:: In the context of events, a phase is set of logical traversals from
+ node to node along the DOM tree, from the Window to the {{Document}}
+ object, root element, and down to the event target (capture
+ phase), at the event target itself (target phase), and
+ back up the same chain (bubbling phase).
+
+: propagation path
+:: The ordered set of current event targets though which an event
+ object will pass sequentially on the way to and back from the event
+ target. As the event propagates, each current event target in
+ the propagation path is in turn set as the {{Event/currentTarget}}. The
+ propagation path is initially composed of one or more event phases as
+ defined by the event type, but MAY be interrupted. Also known as an
+ event target chain.
+
+: target phase
+:: The process by which an event can be handled by the event
+ target. See the description of the target phase in the context of
+ event flow for more details.
+
+: user agent
+:: A program, such as a browser or content authoring tool, normally running on
+ a client machine, which acts on a user's behalf in retrieving, interpreting,
+ executing, presenting, or creating content. Users MAY act on the content
+ using different user agents at different times, for different purposes.
+
+: Window
+:: The Window is the object referred to by the current document's
+ browsing context's Window Proxy object as defined in
+ HTML5
+ [[HTML5]].
+
+
To the extent possible under law, the editors have waived all copyright
+and related or neighboring rights to this work.
+In addition, as of 21 June 2024,
+the editors have made this specification available under the Open Web Foundation Agreement Version 1.0,
+which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0.
+Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.
+
+
+
+
Abstract
+
This document provides a non-normative description of the DOM Event architecture.
+
+ It was previously part of the UI Events spec.
+
+
+
+
+
+
1. DOM Event Architecture
+
This section is non-normative. Refer to [DOM] for a normative description
+of the DOM event architecture
+
This information in this document was previously included in the UIEvents spec, but
+has been removed to this document so avoid confusion. As noted above, the proper
+definitions are part of the [DOM] specification.
+
1.1. Event dispatch and DOM event flow
+
This section gives a brief overview of the event dispatch mechanism
+ and describes how events propagate through the DOM tree. Applications can
+ dispatch event objects using the dispatchEvent() method, and
+ the event object will propagate through the DOM tree as determined by the
+ DOM event flow.
+
+
+ Graphical representation of an event dispatched in a DOM tree using the DOM event flow
+
+
Event objects are dispatched to an event target. But before dispatch
+ can begin, the event object’s propagation path must first be
+ determined.
+
The propagation path is an ordered list of current event
+ targets through which the event passes. This propagation path reflects
+ the hierarchical tree structure of the document. The last item in the list
+ is the event target, and the preceding items in the list are referred
+ to as the target’s ancestors, with the immediately preceding item
+ as the target’s parent.
+
Once the propagation path has been determined, the event object
+ passes through one or more event phases. There are three event
+ phases: capture phase, target phase and bubble phase.
+ Event objects complete these phases as described below. A phase will be
+ skipped if it is not supported, or if the event object’s propagation has
+ been stopped. For example, if the bubbles attribute is set to
+ false, the bubble phase will be skipped, and if stopPropagation() has been called prior to the dispatch, all phases will be skipped.
+
+
+
The capture phase: The event object propagates
+through the target’s ancestors from the Window to the target’s
+parent. This phase is also known as the capturing phase.
+
+
The target phase: The event object arrives at the event
+object’s event target. This phase is also known as the at-target phase. If the event type indicates that the
+event doesn’t bubble, then the event object will halt after completion
+of this phase.
+
+
The bubble phase: The event object propagates through
+the target’s ancestors in reverse order, starting with the target’s
+parent and ending with the Window. This phase is also known as
+the bubbling phase.
+
+
1.2. Default actions and cancelable events
+
Events are typically dispatched by the implementation as a result of a user
+ action, in response to the completion of a task, or to signal progress
+ during asynchronous activity (such as a network request). Some events can be
+ used to control the behavior that the implementation may take next (or undo
+ an action that the implementation already took). Events in this category are
+ said to be cancelable and the behavior they cancel is called their default action. Cancelable event objects can be associated
+ with one or more 'default actions'. To cancel an event, call the preventDefault() method.
+
A EVENT{mousedown} event is dispatched immediately after the user presses
+ down a button on a pointing device (typically a mouse). One possible default action taken by the implementation is to set up a state
+ machine that allows the user to drag images or select text. The default
+ action depends on what happens next — for example, if the user’s
+ pointing device is over text, a text selection might begin. If the user’s
+ pointing device is over an image, then an image-drag action could begin.
+ Preventing the default action of a EVENT{mousedown} event prevents
+ these actions from occurring.
+
Default actions are usually performed after the event dispatch has
+ been completed, but in exceptional cases they may also be performed
+ immediately before the event is dispatched.
+
The default action associated with the EVENT{click} event on <input
+ type="checkbox"> elements toggles the checked IDL
+ attribute value of that element. If the EVENT{click} event’s default action
+ is cancelled, then the value is restored to its former state.
+
When an event is canceled, then the conditional default actions associated with the event is skipped (or as mentioned above, if the default actions are carried out before the dispatch, their effect
+ is undone). Whether an event object is cancelable is indicated by
+ the cancelable attribute. Calling preventDefault() stops all
+ related default actions of an event object. The defaultPrevented attribute indicates whether an event has already
+ been canceled (e.g., by a prior event listener). If the DOM
+ application itself initiated the dispatch, then the return value of the dispatchEvent() method indicates whether the event object
+ was cancelled.
+
Many implementations additionally interpret an event
+ listener’s return value, such as the value false, to mean that
+ the default action of cancelable events will be cancelled (though window.onerror handlers are cancelled by returning true).
+
1.3. Synchronous and asynchronous events
+
Events may be dispatched either synchronously or asynchronously.
+
Events which are synchronous (sync events) are treated
+ as if they are in a virtual queue in a first-in-first-out model, ordered by
+ sequence of temporal occurrence with respect to other events, to changes in
+ the DOM, and to user interaction. Each event in this virtual queue is
+ delayed until the previous event has completed its propagation behavior, or
+ been canceled. Some sync events are driven by a specific device or process,
+ such as mouse button events. These events are governed by the event
+ order algorithms defined for that set of events, and user agents will
+ dispatch these events in the defined order.
+
Events which are asynchronous (async events) may be
+ dispatched as the results of the action are completed, with no relation to
+ other events, to other changes in the DOM, nor to user interaction.
+
During loading of a document, an inline script element is parsed and
+ executed. The EVENT{load} event is queued to be fired
+ asynchronously at the script element. However, because it is an async event,
+ its order with relation to other synchronous events fired during document
+ load (such as the DOMContentLoaded event from [HTML5]) is not guaranteed.
+
1.4. Trusted events
+
Events that are generated by the user agent, either as a result of user
+ interaction, or as a direct result of changes to the DOM, are trusted by the user agent with privileges that are not afforded to events generated by
+ script through the createEvent() method, modified
+ using the initEvent() method, or dispatched via the dispatchEvent() method. The isTrusted attribute
+ of trusted events has a value of true, while untrusted events
+ have a isTrusted attribute value of false.
+
Most untrusted events will not trigger default actions, with the
+ exception of the EVENT{click} event. This event always
+ triggers the default action, even if the isTrusted attribute is false (this behavior is retained for
+ backward-compatibility). All other untrusted events behave as if the preventDefault() method had been called on that event.
+
1.5. Activation triggers and behavior
+
Certain event targets (such as a link or button element) may have
+ associated activation behavior (such as following a link) that
+ implementations perform in response to an activation
+ trigger (such as clicking a link).
+
Both HTML and SVG have an <a> element which indicates a
+ link. Relevant activation triggers for an <a> element are a EVENT{click} event on the text or image content
+ of the <a> element, or a EVENT{keydown}
+ event with a key attribute value of KEY{Enter} key when
+ the <a> element has focus. The activation behavior for
+ an <a> element is normally to change the content of the
+ window to the content of the new document, in the case of external links,
+ or to reposition the current document relative to the new anchor, in the
+ case of internal links.
+
An activation trigger is a user action or an event which indicates
+ to the implementation that an activation behavior should be initiated.
+ User-initiated activation triggers include clicking a mouse button
+ on an activatable element, pressing the KEYCAP{Enter} key when an activatable
+ element has focus, or pressing a key that is somehow linked to an
+ activatable element (a hotkey or access key) even when that
+ element does not have focus. Event-based activation triggers may
+ include timer-based events that activate an element at a certain clock time
+ or after a certain time period has elapsed, progress events after a certain
+ action has been completed, or many other condition-based or state-based
+ events.
+
1.6. Constructing Mouse and Keyboard Events
+
Generally, when a constructor of an Event interface, or of an interface
+ inherited from the Event interface, is invoked, the steps described in [DOM] should be followed. However the KeyboardEvent and MouseEvent interfaces provide additional dictionary members for
+ initializing the internal state of the Event object’s key modifiers:
+ specifically, the internal state queried for using the getModifierState() and getModifierState() methods. This section supplements the DOM4 steps for intializing a new Event object with these optional modifier states.
+
For the purposes of constructing a KeyboardEvent, MouseEvent, or
+ object derived from these objects using the algorithm below, all KeyboardEvent, MouseEvent, and derived objects have internal key modifier state which can be set and
+ retrieved using the key modifier names described in the Modifier Keys table in [UIEvents-Key].
+
The following steps supplement the algorithm defined for constructing
+ events in DOM4:
+
+
+
If the Event being constructed is a KeyboardEvent or MouseEvent object or an object that derives from either of these,
+and a EventModifierInit argument was provided to the constructor,
+then run the following sub-steps:
+
+
+
For each EventModifierInit argument, if the dictionary member
+begins with the string "modifier", then let the key modifier name be the
+dictionary member’s name excluding the prefix "modifier", and set the Event object’s internal key modifier state that matches the key modifier name to the corresponding value.
+
+
+
+
+
2. Glossary
+
Some 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.
+
+
activation behavior
+
+
The action taken when an event, typically initiated by users through
+an input device, causes an element to fulfill a defined task. The task MAY
+be defined for that element by the host language, or by
+author-defined variables, or both. The default task for any given element
+MAY be a generic action, or MAY be unique to that element. For example, the
+activation behavior of an HTML or SVG <a> element is to
+cause the user agent to traverse the link specified in the href attribute, with the further optional parameter of
+specifying the browsing context for the traversal (such as the current
+window or tab, a named window, or a new window). The activation behavior of
+an HTML <input> element with the type attribute value submit is be to send the values of the form
+elements to an author-defined IRI by the author-defined HTTP method.
The process by which an event can be handled by one of the target’s
+ancestors after being handled by the event target. See the
+description of the bubble phase in the context of event flow for more
+details.
+
capture phase
+
+
The process by which an event can be handled by one of the target’s
+ancestors before being handled by the event target. See the
+description of the capture phase in the context
+of event flow for more details.
+
current event target
+
+
In an event flow, the current event target is the object associated with the event handler that is currently being dispatched. This object MAY be
+the event target itself or one of its ancestors. The current event
+target changes as the event propagates from object to object through
+the various phases of the event flow. The current event target is the
+value of the currentTarget attribute.
+
default action
+
+
A default action is an OPTIONAL supplementary behavior that an
+implementation MUST perform in combination with the dispatch of the event
+object. Each event type definition, and each specification, defines the default action for that event type, if it has one. An instance of an
+event MAY have more than one default action under some circumstances,
+such as when associated with an activation trigger. A default
+action MAY be cancelled through the invocation of the preventDefault() method.
+
dispatch
+
+
To create an event with attributes and methods appropriate to its type and
+context, and propagate it through the DOM tree in the specified manner.
+Interchangeable with the term fire, e.g., fire a
+EVENT{click} event or dispatch a EVENT{load} event.
+
document
+
+
An object instantiating the Document interface [DOM-Level-3-Core],
+representing the entire HTML or XML text document. Conceptually, it is the
+root of the document tree, and provides the primary access to the document’s
+data.
+
DOM application
+
+
A DOM application is script or code, written by a content author or
+automatically generated, which takes advantage of the interfaces, methods,
+attributes, events, and other features described in this specification in
+order to make dynamic or interactive content, such as Web applications,
+exposed to users in a user agent.
+
event
+
+
An event is the representation of some occurrence (such as a mouse click on
+the presentation of an element, the removal of child node from an element,
+or any number of other possibilities) which is associated with its event
+target. Each event is an instantiation of one specific event
+type.
+
event handler
+
event listener
+
+
An object that implements the EventListener interface and provides an handleEvent() callback method. Event handlers are
+language-specific. Event handlers are invoked in the context of a particular
+object (the current event target) and are provided with the event
+object itself.
+
In JavaScript, user-defined functions are considered to implement the EventListener interface. Thus the event object will be provided as the
+first parameter to the user-defined function when it is invoked.
+Additionally, JavaScript objects can also implement the EventListener interface when they define a handleEvent() method.
+
event order
+
+
The sequence in which events from the same event source or process occur,
+using the same or related event interfaces. For example, in an environment
+with a mouse, a track pad, and a keyboard, each of those input devices would
+constitute a separate event source, and each would follow its own event
+order. A EVENT{mousedown} event from the trackpad followed by a
+EVENT{mouseup} event from the mouse would not result in a EVENT{click} event.
+
There can be interactions between different event orders. For example, a
+EVENT{click} event might be modified by a concurrent EVENT{keydown} event
+(e.g., via KEYCAP{Shift}+EVENT{click}). However, the event
+orders of these different event sources would be distinct.
+
The event order of some interfaces are device-independent. For example, a
+user might change focus using the KEYCAP{Tab} key, or by clicking the new
+focused element with the mouse. The event order in such cases depends on
+the state of the process, not on the state of the device that initiates the
+state change.
Any language which integrates the features of another language or API
+specification, while normatively referencing the origin specification rather
+than redefining those features, and extending those features only in ways
+defined by the origin specification. An origin specification typically is
+only intended to be implemented in the context of one or more host
+languages, not as a standalone language. For example, XHTML, HTML, and SVG
+are host languages for UI Events, and they integrate and extend the objects
+and models defined in this specification.
The ordered set of current event targets though which an event object will pass sequentially on the way to and back from the event
+target. As the event propagates, each current event target in
+the propagation path is in turn set as the currentTarget. The
+propagation path is initially composed of one or more event phases as
+defined by the event type, but MAY be interrupted. Also known as an event target chain.
+
target phase
+
+
The process by which an event can be handled by the event
+target. See the description of the target phase in the context of
+event flow for more details.
+
user agent
+
+
A program, such as a browser or content authoring tool, normally running on
+a client machine, which acts on a user’s behalf in retrieving, interpreting,
+executing, presenting, or creating content. Users MAY act on the content
+using different user agents at different times, for different purposes.
+
Window
+
+
The Window is the object referred to by the current document’s
+browsing context’s Window Proxy object as defined in HTML5[HTML5].
+
+
+
+
+
Conformance
+
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology.
+ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
+ in the normative parts of this document
+ are to be interpreted as described in RFC 2119.
+ However, for readability,
+ these words do not appear in all uppercase letters in this specification.
+
All of the text of this specification is normative
+ except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
+
Examples in this specification are introduced with the words “for example”
+ or are set apart from the normative text with class="example", like this:
+
This is an example of an informative example.
+
Informative notes begin with the word “Note”
+ and are set apart from the normative text with class="note", like this:
path: sections/event-interfaces.include
diff --git a/sections/event-keyboardevent.txt b/sections/event-keyboardevent.txt
index 3e7c33c..94c61b2 100644
--- a/sections/event-keyboardevent.txt
+++ b/sections/event-keyboardevent.txt
@@ -529,8 +529,7 @@
current focus is on a state-changing element, the default action
MUST be to dispatch a EVENT{click} event, and a
EVENT{DOMActivate} event if that event type is supported by the
- user agent (refer to [[#event-flow-activation]] for more
- details)
+ user agent.
If this event is canceled, the associated event types MUST NOT be
dispatched, and the associated actions MUST NOT be performed.
diff --git a/sections/event-mouseevent.txt b/sections/event-mouseevent.txt
index 2d923ba..8db9cc5 100644
--- a/sections/event-mouseevent.txt
+++ b/sections/event-mouseevent.txt
@@ -33,7 +33,7 @@
When initializing {{MouseEvent}} objects using initMouseEvent,
implementations can use the client coordinates {{MouseEvent/clientX}}
and {{MouseEvent/clientY}} for calculation of other coordinates (such
- as target coordinates exposed by DOM Level 0 implementations or
+ as target coordinates exposed by DOM Level 0 implementations or
other proprietary attributes, e.g., pageX).
@@ -400,7 +400,7 @@
{{KeyboardEvent}} interfaces, as well as the additional modifier states
queried via {{KeyboardEvent/getModifierState()}}. The steps for
constructing events using this dictionary are defined in the
- event constructors section.
+ MouseEvent constructors section.
Constructing Mouse Events
+
+ Generally, when a constructor of an {{Event}} interface, or of an interface
+ inherited from the {{Event}} interface, is invoked, the steps described in
+ [[!DOM]] should be followed. However the
+ {{MouseEvent}} interfaces provide additional dictionary members for
+ initializing the internal state of the {{Event}} object's key modifiers:
+ specifically, the internal state queried for using the
+ {{MouseEvent/getModifierState()}}
+ methods. This section supplements the DOM4 steps for intializing a new
+ {{MouseEvent}} object with these optional modifier states.
+
+ For the purposes of constructing a {{MouseEvent}}, or
+ object derived from these objects using the algorithm below, all
+ {{MouseEvent}}, and derived objects have
+ internal key modifier state which can be set and
+ retrieved using the key modifier names
+ described in the
+ Modifier Keys table
+ in [[UIEvents-Key]].
+
+ The following steps supplement the algorithm defined for constructing
+ events in DOM4:
+
+ * If the {{Event}} being constructed is a
+ {{MouseEvent}} object or an object that derives from it,
+ and a {{EventModifierInit}} argument was provided to the constructor,
+ then run the following sub-steps:
+
+ * For each {{EventModifierInit}} argument, if the dictionary member
+ begins with the string "modifier", then let the
+ key modifier name be the
+ dictionary member's name excluding the prefix
+ "modifier", and set the {{Event}} object's
+ internal key modifier state
+ that matches the key modifier name
+ to the corresponding value.
+
MouseEvent Algorithms
Native OS Requirements
@@ -1315,7 +1353,7 @@
* If the event target has associated activation behavior,
the default action MUST be to execute that activation
- behavior (see [[#event-flow-activation]]).
+ behavior.
Receiving and handling auxclick for the middle button.
@@ -1446,7 +1484,7 @@ myDiv.addEventListener("auxclick", function(e) {
In addition to being associated with pointer devices, the
EVENT{click} event type MUST be dispatched as part of an element
- activation, as described in [[#event-flow-activation]].
+ activation.
For maximum accessibility, content authors are encouraged to use the
@@ -1466,7 +1504,7 @@ myDiv.addEventListener("auxclick", function(e) {
* If the event target has associated activation behavior,
the default action MUST be to execute that activation
- behavior (see [[#event-flow-activation]]).
+ behavior.
* If the event target is focusable, the default
action MUST be to give that element document focus.
diff --git a/sections/glossary.txt b/sections/glossary.txt
index 2b0cf6e..630b742 100644
--- a/sections/glossary.txt
+++ b/sections/glossary.txt
@@ -6,25 +6,8 @@ similar definitions in other W3C or standards documents. See the links within
the definitions for more information.
-: activation behavior
-:: The action taken when an event, typically initiated by users through
- an input device, causes an element to fulfill a defined task. The task MAY
- be defined for that element by the host language, or by
- author-defined variables, or both. The default task for any given element
- MAY be a generic action, or MAY be unique to that element. For example, the
- activation behavior of an HTML or SVG <a> element is to
- cause the user agent to traverse the link specified in the
- href attribute, with the further optional parameter of
- specifying the browsing context for the traversal (such as the current
- window or tab, a named window, or a new window). The activation behavior of
- an HTML <input> element with the type
- attribute value submit is be to send the values of the form
- elements to an author-defined IRI by the author-defined HTTP method. See
- [[#event-flow-activation]] for more details.
-
: activation trigger
-:: An event which is defined to initiate an activation behavior. Refer
- to [[#event-flow-activation]] for more details.
+:: An event which is defined to initiate an activation behavior.
: author
:: In the context of this specification, an author, content
@@ -38,18 +21,6 @@ the definitions for more information.
document. In a well-formed HTML document, the body element is a first
descendant of the root element.
-: bubbling phase
-:: The process by which an event can be handled by one of the target's
- ancestors after being handled by the event target. See the
- description of the bubble phase in the context of event flow for more
- details.
-
-: capture phase
-:: The process by which an event can be handled by one of the target's
- ancestors before being handled by the event target. See the
- description of the capture phase in the context
- of event flow for more details.
-
: character value
:: In the context of key values, a character value is a string representing one
or more Unicode characters, such as a letter or symbol, or a set of letters, each
@@ -64,14 +35,6 @@ the definitions for more information.
use.
-: current event target
-:: In an event flow, the current event target is the object associated with the
- event handler that is currently being dispatched. This object MAY be
- the event target itself or one of its ancestors. The current event
- target changes as the event propagates from object to object through
- the various phases of the event flow. The current event target is the
- value of the {{Event/currentTarget}} attribute.
-
: dead key
:: A dead key is a key or combination of keys which produces no character by
itself, but which in combination or sequence with another key produces a
@@ -86,8 +49,7 @@ the definitions for more information.
event MAY have more than one default action under some circumstances,
such as when associated with an activation trigger. A default
action MAY be cancelled through the invocation of the
- {{Event/preventDefault()}} method. For more details, see
- [[#event-flow-default-cancel]].
+ {{Event/preventDefault()}} method.
: delta
:: The estimated scroll amount (in pixels, lines, or pages) that the user agent
@@ -118,45 +80,11 @@ the definitions for more information.
marked as deprecated in this specification are expected to be dropped from
future specifications.
-: dispatch
-:: To create an event with attributes and methods appropriate to its type and
- context, and propagate it through the DOM tree in the specified manner.
- Interchangeable with the term fire, e.g., fire a
- EVENT{click} event or dispatch a EVENT{load} event.
-
-: document
-:: An object instantiating the {{Document}} interface [[DOM-Level-3-Core]],
- representing the entire HTML or XML text document. Conceptually, it is the
- root of the document tree, and provides the primary access to the document's
- data.
-
-: DOM application
-:: A DOM application is script or code, written by a content author or
- automatically generated, which takes advantage of the interfaces, methods,
- attributes, events, and other features described in this specification in
- order to make dynamic or interactive content, such as Web applications,
- exposed to users in a user agent.
-
-: DOM Level 0
-:: The term DOM Level 0 refers to a mix of HTML document functionalities,
- often not formally specified but traditionally supported as de facto
- standards, implemented originally by Netscape Navigator version 3.0 or
- Microsoft Internet Explorer version 3.0. In many cases, attributes or
- methods have been included for reasons of backward compatibility with DOM
- Level 0.
-
: empty string
:: The empty string is a value of type DOMString of length
0, i.e., a string which contains no characters (neither
printing nor control characters).
-: event
-:: An event is the representation of some occurrence (such as a mouse click on
- the presentation of an element, the removal of child node from an element,
- or any number of other possibilities) which is associated with its event
- target. Each event is an instantiation of one specific event
- type.
-
: event focus
:: Event focus is a special state of receptivity and concentration on a
particular element or other event target within a document. Each
@@ -176,47 +104,8 @@ the definitions for more information.
rings, focus wraps around from the last focus target to the
first.
-: event handler
-: event listener
-:: An object that implements the {{EventListener}} interface and provides an
- {{EventListener/handleEvent()}} callback method. Event handlers are
- language-specific. Event handlers are invoked in the context of a particular
- object (the current event target) and are provided with the event
- object itself.
-
-
- In JavaScript, user-defined functions are considered to implement the
- {{EventListener}} interface. Thus the event object will be provided as the
- first parameter to the user-defined function when it is invoked.
- Additionally, JavaScript objects can also implement the {{EventListener}}
- interface when they define a {{EventListener/handleEvent()}} method.
-
-
-: event order
-:: The sequence in which events from the same event source or process occur,
- using the same or related event interfaces. For example, in an environment
- with a mouse, a track pad, and a keyboard, each of those input devices would
- constitute a separate event source, and each would follow its own event
- order. A EVENT{mousedown} event from the trackpad followed by a
- EVENT{mouseup} event from the mouse would not result in a EVENT{click} event.
-
-
- There can be interactions between different event orders. For example, a
- EVENT{click} event might be modified by a concurrent EVENT{keydown} event
- (e.g., via KEYCAP{Shift}+EVENT{click}). However, the event
- orders of these different event sources would be distinct.
-
- The event order of some interfaces are device-independent. For example, a
- user might change focus using the KEYCAP{Tab} key, or by clicking the new
- focused element with the mouse. The event order in such cases depends on
- the state of the process, not on the state of the device that initiates the
- state change.
-
-: event phase
-:: See phase.
-
: event target
-:: The object to which an event is targeted using the [[#event-flow]].
+:: The object to which an event is targeted using the event flow.
The event target is the value of the {{Event/target}} attribute.
: event type
@@ -229,9 +118,6 @@ the definitions for more information.
Also loosely referred to as "event", such as the
EVENT{click} event.
-: fire
-:: A synonym for dispatch.
-
: host language
:: Any language which integrates the features of another language or API
specification, while normatively referencing the origin specification rather
@@ -291,22 +177,6 @@ the definitions for more information.
XML Namespaces
regarding URIs and namespace URIs handling and comparison in the DOM APIs.
-: phase
-:: In the context of events, a phase is set of logical traversals from
- node to node along the DOM tree, from the Window to the {{Document}}
- object, root element, and down to the event target (capture
- phase), at the event target itself (target phase), and
- back up the same chain (bubbling phase).
-
-: propagation path
-:: The ordered set of current event targets though which an event
- object will pass sequentially on the way to and back from the event
- target. As the event propagates, each current event target in
- the propagation path is in turn set as the {{Event/currentTarget}}. The
- propagation path is initially composed of one or more event phases as
- defined by the event type, but MAY be interrupted. Also known as an
- event target chain.
-
: QWERTY
:: QWERTY (pronounced ˈkwɜrti) is a common keyboard layout,
so named because the first five character keys on the top row of letter keys
@@ -324,11 +194,6 @@ the definitions for more information.
a wheel, while on others, it MAY be movement along a flat surface, or
pressure on a particular button.
-: target phase
-:: The process by which an event can be handled by the event
- target. See the description of the target phase in the context of
- event flow for more details.
-
: text composition system
:: A software component that interprets some form of alternate input (such as a
input method editor, a speech processor, or a handwriting recognition
@@ -373,18 +238,4 @@ the definitions for more information.
immediately after a new event has been created using the method
{{Document/createEvent()}}.
-: user agent
-:: A program, such as a browser or content authoring tool, normally running on
- a client machine, which acts on a user's behalf in retrieving, interpreting,
- executing, presenting, or creating content. Users MAY act on the content
- using different user agents at different times, for different purposes. See
- the [[#conf-interactive-ua]] and [[#conf-author-tools]] for details on the
- requirements for a conforming user agent.
-
-: Window
-:: The Window is the object referred to by the current document's
- browsing context's Window Proxy object as defined in
- HTML5
- [[HTML5]].
-
diff --git a/sections/introduction.txt b/sections/introduction.txt
index 799edbf..08d1db5 100644
--- a/sections/introduction.txt
+++ b/sections/introduction.txt
@@ -5,7 +5,7 @@
Overview
UI Events is designed with two main goals. The first goal is the design of
- an event system which allows registration of event listeners and
+ an event system which allows registration of [=event listeners=] and
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
@@ -56,8 +56,6 @@
* the Core module defined in [[DOM-Level-3-Core]]
- * the [[#event-flow]] mechanism
-
* all the interfaces and events with their associated methods,
attributes, and semantics defined in this specification with the
exception of those marked as deprecated (a conforming user
@@ -89,7 +87,7 @@
but such implementation is discouraged.
A conforming browser MAY also support features not found in this
- specification, but which use the [[#event-flow]] mechanism, interfaces,
+ specification, but which use the interfaces,
events, or other features defined in this specification, and MAY
implement additional interfaces and event types appropriate to
that implementation. Such features can be later standardized in future
@@ -107,7 +105,7 @@
Authoring tools
A content authoring tool conforms to UI Events if it produces content
- which uses the event types and [[#event-flow]] model, consistent
+ which uses the event types, consistent
in a manner as defined in this specification.
A content authoring tool MUST NOT claim conformance to UI Events for
@@ -121,7 +119,7 @@
Content authors and content
A content author creates conforming UI Events content if that
- content uses the event types and [[#event-flow]] model,
+ content uses the event types
consistent in a manner as defined in this specification.
A content author SHOULD NOT use features of this specification
@@ -141,7 +139,7 @@
Specifications and host languages
A specification or host language conforms to UI Events if it
- references and uses the [[#event-flow]] mechanism, interfaces, events,
+ references and uses the event flow mechanism, interfaces, events,
or other features defined in [[!DOM]], and does not extend
these features in incompatible ways.
diff --git a/sections/legacy-event-types.txt b/sections/legacy-event-types.txt
index f205d34..e3ba552 100644
--- a/sections/legacy-event-types.txt
+++ b/sections/legacy-event-types.txt
@@ -110,8 +110,7 @@ completeness.
A user agent MUST dispatch this event when a button, link, or
- other state-changing element is activated. Refer to
- [[#event-flow-activation]] for more details.
+ other state-changing element is activated.
The EVENT{DOMActivate} event type is defined in this
@@ -156,9 +155,9 @@ completeness.
conforming to UI Events, the XForms user agent has to determine
whether to synthesize a EVENT{DOMActivate} event with the same relevant
properties as a default action of that EVENT{click} event.
- Appropriate cues might be whether the EVENT{click} event is trusted, or whether its event target
- has a EVENT{DOMActivate} event listener registered.
+ Appropriate cues might be whether the EVENT{click} event {{Event/isTrusted}},
+ or whether its event target
+ has a EVENT{DOMActivate} [=event listener=] registered.
diff --git a/sections/security.txt b/sections/security.txt
index d7a574b..b52b6a5 100644
--- a/sections/security.txt
+++ b/sections/security.txt
@@ -12,11 +12,11 @@ Implementers SHOULD consult the specifications of such features for their
respective security considerations.
Many of the event types defined in this specification are dispatched in response
-to user actions. This allows malicious event listeners to gain access to
+to user actions. This allows malicious [=event listeners=] to gain access to
information users would typically consider confidential, e.g., typos they might
have made when filling out a form, if they reconsider their answer to a multiple
choice question shortly before submitting a form, their typing rate or primary
-input mechanism. In the worst case, malicious event listeners could capture all
+input mechanism. In the worst case, malicious [=event listeners=] could capture all
user interactions and submit them to a third party through means (not defined in
this specification) that are generally available in DOM implementations, such as
the XMLHttpRequest interface.
@@ -25,7 +25,7 @@ In DOM implementations that support facilities to load external data, events
like the EVENT{error} event can provide access to sensitive information about
the environment of the computer system or network. An example would be a
malicious HTML document that attempts to embed a resource on the local network
-or the localhost on different ports. An embedded DOM application could
+or the localhost on different ports. An embedded DOM application could
then listen for EVENT{error} and EVENT{load} events to determine which other
computers in a network are accessible from the local system or which ports are
open on the system to prepare further attacks.
@@ -33,8 +33,8 @@ open on the system to prepare further attacks.
An implementation of UI Events alone is generally insufficient to perform
attacks of this kind and the security considerations of the facilities that
possibly support such attacks apply. For conformance with this specification,
-DOM implementations MAY take reasonable steps to ensure that DOM
-applications do not get access to confidential or sensitive information. For
+DOM implementations MAY take reasonable steps to ensure that DOM
+applications do not get access to confidential or sensitive information. For
example, they might choose not to dispatch EVENT{load} events to nodes that
attempt to embed resources on the local network.
+