--- a/html/DOM3-Events.html Sat Jun 28 20:56:25 2008 +0900
+++ b/html/DOM3-Events.html Thu Jul 10 03:00:31 2008 +0900
@@ -20,8 +20,9 @@
<style type="text/css">
.issue {
- background-color: #ffffbf;
- border: 2px dashed red;
+ background-color: darkgray;
+ color: white;
+ /* border: 2px dashed red; */
}
.note {
color:green;
@@ -52,8 +53,23 @@
#tbl-keyIdentifiers-keyCode-charCode th { text-align: center; font-weight: bold }
- #tbl-keyIdentifiers-keyCode-charCode th { vertical-align: middle }
+ #tbl-keyIdentifiers-keyCode-charCode th { vertical-align: middle; font-size: 0.85em; }
#tbl-keyIdentifiers-keyCode-charCode td { vertical-align: middle; text-align: center; }
+
+ .smallRow1 th {
+ font-size: 0.75em;
+ display:block;
+ width:1.5em;
+ height:1.5em;
+ height:auto;
+ }
+
+ .verticalCell1 {
+ display:block;
+ width:1.5em;
+ height:1.5em;
+ height:auto;
+ }
#tbl-keyIdentifiers-keyCode-charCode td:first-child + td + td + td + td,
#tbl-keyIdentifiers-keyCode-charCode td:first-child + td + td + td + td + td + td + td + td + td + td,
@@ -107,10 +123,10 @@
<dl>
<dt>Editors:</dt>
<dd>Doug Schepers, W3C</dd>
- <dd><a href="http://andrew.emmons.com/">Andrew Emmons</a>, <i>Invited Expert</i></dd>
+ <dd><a href="http://andrew.emmons.com/">Andrew Emmons</a>, <em>Invited Expert</em></dd>
<dd><a href="http://bjoern.hoehrmann.de/">Björn Höhrmann</a> Invited Expert (until December 2007)</dd>
- <dd>Philippe Le Hégaret, <i>W3C (until November 2003)</i></dd>
- <dd>Tom Pixley, <i>Netscape Communications Corporation (until July 2002)</i></dd>
+ <dd>Philippe Le Hégaret, <em>W3C (until November 2003)</em></dd>
+ <dd>Tom Pixley, <em>Netscape Communications Corporation (until July 2002)</em></dd>
</dl>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2008 <a href="http://www.w3.org/">
<acronym title="World Wide Web Consortium">W3C</acronym>
@@ -304,6 +320,11 @@
</li>
<li class="tocline3">
<a class="tocxref" href="#keyset-KeySet-Set">A.2 Key identifiers set</a>
+ <ul class="toc">
+ <li class="tocline4">
+ <a class="tocxref" href="#keyset-KeySet-Set-keyCode-charCode">A.2.1 Key identifiers, keyCode, and charCode</a>
+ </li>
+ </ul>
</li>
</ul>
</li>
@@ -449,7 +470,7 @@
<a name="events-Events" id="events-Events"> </a>
<h1 id="events-Events-h1" class="div1">1. Document Object Model Events</h1>
<dl>
- <dt><i>Editors</i>:</dt>
+ <dt><em>Editors</em>:</dt>
<dd>Doug Schepers, W3C</dd>
<dd><a href="http://bjoern.hoehrmann.de/">Björn Höhrmann</a> Invited Expert (until December 2007)</dd>
<dd>Philippe Le Hégaret, W3C (until November 2003)</dd>
@@ -596,7 +617,7 @@
<p>An implementation conforms to an event type if it conforms to its associated semantics and DOM interfaces. This includes that event objects that are generated by the implementation are generated as outlined in the tabular definition of the event type.</p>
<p>An implementation which does not conform to an event module can still implement the DOM interfaces associated with it. The DOM application can then create an event object using the <a href="#events-Events-DocumentEvent-createEvent">
<code>DocumentEvent.createEvent()</code>
- </a> method and dispatch an event type associated with this interface using the <a href="#events-Events-EventTarget-dispatchEvent">
+ </a> method and <a href="#glossary-dt-dispatch">dispatch</a> an event type associated with this interface using the <a href="#events-Events-EventTarget-dispatchEvent">
<code>EventTarget.dispatchEvent()</code>
</a> method.</p>
<p>A DOM application may use the <code>hasFeature(feature, version)</code> method of the <code>DOMImplementation</code> interface with parameter values <code>"Events"</code> and <code>"3.0"</code> (respectively) to determine whether or not DOM Level 3 Events is supported by the implementation. Since DOM Level 3 Events is built on top of DOM Level 2 Events [<cite>
@@ -613,31 +634,31 @@
<div class="div2">
<a name="events-Events-flow" id="events-Events-flow"> </a>
<h2 id="events-Events-flow-h2" class="div2">1.2 Event dispatch and DOM event flow</h2>
- <p>This section defines the event dispatch mechanism of the event model defined in this specification. Applications may dispatch event objects using the <a href="#events-Events-EventTarget-dispatchEvent">
+ <p>This section defines the event <a href="#glossary-dt-dispatch">dispatch</a> mechanism of the event model defined in this specification. Applications may dispatch event objects using the <a href="#events-Events-EventTarget-dispatchEvent">
<code>EventTarget.dispatchEvent()</code>
- </a> method, and implementations must dispatch event objects as if through this method. The behavior of this method depends on the <i>event flow</i> associated with the underlying object. An event flow describes how event objects <i>propagate</i> through a data structure. As an example, when an event object is dispatched to an element in an XML document, the object propagates through parts of the document, as determined by the DOM event flow which is defined at the end of this section.</p>
+ </a> method, and implementations must dispatch event objects as if through this method. The behavior of this method depends on the <em>event flow</em> associated with the underlying object. An event flow describes how event objects <em>propagate</em> through a data structure. As an example, when an event object is dispatched to an element in an XML document, the object propagates through parts of the document, as determined by the DOM event flow which is defined at the end of this section.</p>
<div class="figure" style="text-align: center">
<img src="images/eventflow.png"
alt="graphical representation of an event dispatched in a DOM tree using the DOM event flow"
title="graphical representation of an event dispatched in a DOM tree using the DOM event flow"/>
- <p style="text-align:left"><i>Figure: graphical representation of an event dispatched in a DOM tree using the DOM event flow</i> [<a href="images/eventflow.svg">SVG 1.0 version</a>]</p>
+ <p style="text-align:left"><em>Figure: graphical representation of an event dispatched in a DOM tree using the DOM event flow</em> [<a href="images/eventflow.svg">SVG 1.0 version</a>]</p>
</div>
- <p>Event objects are always dispatched to an event target called the <i>event's target</i>. At the beginning of the dispatch, implementations must first determine the event object's <i>propagation path</i>. This is an ordered list of event targets the object may propagate to. The last item in the list is the event's target; the preceding items in the list are referred to as the <i>target's ancestors</i> and the immediately preceding item as the <i>target's parent</i>. Once determined, the propagation path cannot be changed. As an example, in the DOM event flow event listeners might change the position of the target node in the document while the event object is being dispatched; such changes do not affect the propagation path.</p>
- <p>As the next step the event object <i>accomplishes</i> one or more <i>event phases</i>. This specification defines the following event phases. Event objects accomplish them in the specified order using the partial propagation paths as defined below. A phase is skipped if it is not supported, or if the event object's propagation has been stopped. For example, if the <a href="#events-Events-Event-canBubble">
+ <p>Event objects are always dispatched to an element called the <em>event target</em>. <span class="issue">Can an event target ever be anything but an element?</span> At the beginning of the dispatch, implementations must first determine the event object's <em>propagation path</em>. The propagation path is an ordered list of event targets through which the object will pass. The last item in the list is the event target; the preceding items in the list are referred to as the <em>target's ancestors</em> and the immediately preceding item as the <em>target's parent</em>. Once determined, the propagation path cannot be changed. As an example, in the DOM event flow event listeners might change the position of the target node in the document while the event object is being dispatched; such changes do not affect the propagation path. <span class="issue">What if an element is removed from the document altogether? Is there different behavior if the event target is removed versus one of its ancestors?</span></p>
+ <p>As the next step the event object <em>accomplishes</em> one or more <em>event phases</em>. This specification defines the following event phases. Event objects accomplish them in the specified order using the partial propagation paths as defined below. A phase is skipped if it is not supported, or if the event object's propagation has been stopped. For example, if the <a href="#events-Events-Event-canBubble">
<code>Event.bubbles</code>
</a> attribute is set to false, the bubble phase is skipped, and if <a href="#events-Events-Event-stopPropagation">
<code>Event.stopPropagation()</code>
</a> has been called prior to the dispatch, all phases will be skipped.</p>
<ol>
- <li>The <i>capture phase</i>: the event object propagates through the target's ancestors to the target's parent. This phase is also known as the <i>capturing phase</i>. Event listeners registered for this phase can handle the event before it reaches its target.</li>
- <li>The <i>target phase</i>: the event object has reached the event's target. This phase is also known as the <i>at-target phase</i>. Event listeners registered for this phase can handle the event once it has reached its target.</li>
- <li>The <i>bubble phase</i>: the event object propagates through the target's ancestors in reverse order, starting with the target's parent. This phase is also known as the <i>bubbling phase</i>. Event listeners registered for this phase can handle the event after it has reached its target.</li>
+ <li>The <strong id="capture-phase">capture phase</strong>: the event object propagates through the target's ancestors to the target's parent. This phase is also known as the <em>capturing phase</em>. Event listeners registered for this phase can handle the event before it reaches its target.</li>
+ <li>The <strong id="target-phase">target phase</strong>: the event object has reached the event's target. This phase is also known as the <em>at-target phase</em>. Event listeners registered for this phase can handle the event once it has reached its target.</li>
+ <li>The <strong id="bubble-phase">bubble phase</strong>: the event object propagates through the target's ancestors in reverse order, starting with the target's parent. This phase is also known as the <em>bubbling phase</em>. Event listeners registered for this phase can handle the event after it has reached its target.</li>
</ol>
<p>Implementations let event objects accomplish an event phase by applying the following steps while there are pending event targets in the partial propagation path for this phase and the event object's propagation has not been stopped through <a href="#events-Events-Event-stopPropagation">
<code>Event.stopPropagation()</code>
</a>.</p>
- <p>Firstly, the implementation must determine the <i>current target</i>. This is the next pending event target in the partial propagation path, starting with the first. From the perspective of an event listener this is the event target the listener has been registered on.</p>
- <p>Secondly, the implementation must determine the current target's <i>candidate event listeners</i>. This is the list of all event listeners that have been registered on the current target in their order of registration. Once determined, the candidate event listeners cannot be changed, adding or removing listeners does not affect the current target's candidate event listeners.</p>
+ <p>First, the implementation must determine the <em>current target</em>. This is the next pending event target in the partial propagation path, starting with the first. From the perspective of an event listener this is the event target the listener has been registered on.</p>
+ <p>Second, the implementation must determine the current target's <em>candidate event listeners</em>. This is the list of all event listeners that have been registered on the current target in their order of registration. Once determined, the candidate event listeners cannot be changed, adding or removing listeners does not affect the current target's candidate event listeners.</p>
<p>Finally, the implementation must process all candidate event listeners in order and trigger each listener if all the following conditions are met. A listener is triggered by invoking the <a href="#events-Events-EventListener-handleEvent">
<code>EventListener.handleEvent()</code>
</a> method or an equivalent binding-specific mechanism.</p>
@@ -647,7 +668,7 @@
<li>The listener has been registered for this event type.</li>
</ul>
<p>As the final step of the event dispatch, for reasons of backwards compatibility, the implementation must reset the event object's internal propagation and default action prevention states. This ensures that an event object may be properly dispatched multiple times while also allowing to prevent the event objects propagation or default actions prior to the event dispatch.</p>
- <p>The model defined above applies regardless of the specific event flow associated with an event target. Each event flow defines how the propagation path is determined and which event phases are supported. The <i>DOM event flow</i> is an application of this model: the propagation path for a <code>Node</code> object is determined by its <code>Node.parentNode</code> chain, and all events accomplish the capture and target phases. Whether an event accomplishes the bubble phase is defined individually for each event type. An alternate application of this model can be found in [<cite>
+ <p>The model defined above applies regardless of the specific event flow associated with an event target. Each event flow defines how the propagation path is determined and which event phases are supported. The <em>DOM event flow</em> is an application of this model: the propagation path for a <code>Node</code> object is determined by its <code>Node.parentNode</code> chain, and all events accomplish the capture and target phases. Whether an event accomplishes the bubble phase is defined individually for each event type. An alternate application of this model can be found in [<cite>
<a class="noxref informative" href="#references-DOMLS">DOM Level 3 Load and Save</a>
</cite>].</p>
<p>The DOM event model is reentrant. Event listeners may perform actions that cause additional events to be dispatched. Such events are handled in a synchronous manner, the event propagation that causes the event listener to be triggered will resume only after the event dispatch of the new event is completed.</p>
@@ -659,8 +680,7 @@
<p>Event objects can have default actions associated with them. These are actions the implementation will perform in combination with the dispatch of the event object, usually after the dispatch has been completed, but in exceptional cases also immediately before the event is dispatched. An example is the [<cite>
<a class="noxref informative" href="#references-HTML40">HTML 4.01</a>
</cite>] form element. When the user submits the form (e.g. by pressing on a submit button), the event <a href="#events-event-submit">submit</a> is dispatched to the element and the default action for this event type is generally to send a request to a Web server with the parameters from the form.</p>
- <p><a name="events-dt-cancelable-event" id="events-dt-cancelable-event"
- /> Some event objects are <i>cancelable</i>, meaning the default action can be prevented from occuring, or, if the default action is carried out before the dispatch, its effect can be reversed. Whether an event object is cancelable is indicated by the <a href="#events-Events-Event-canCancel">
+ <p><a name="events-dt-cancelable-event" id="events-dt-cancelable-event"/> Some event objects are <em>cancelable</em>, meaning the default action can be prevented from occuring, or, if the default action is carried out before the dispatch, its effect can be reversed. Whether an event object is cancelable is indicated by the <a href="#events-Events-Event-canCancel">
<code>Event.cancelable</code>
</a> attribute. Event listeners can cancel default actions of cancelable event objects by invoking the <a href="#events-Events-Event-preventDefault">
<code>Event.preventDefault()</code>
@@ -676,7 +696,7 @@
<a name="events-Events-flow-activation" id="events-Events-flow-activation"> </a>
<h2 id="events-Events-flow-activation-h2" class="div2">1.4 Activation requests and behavior</h2>
<p>(This section is currently being rewritten.)</p>
- <p>Event targets may have associated <i>activation behavior</i> that implementations perform in response to an <i>activation request</i>. As an example, the typical activiation behavior associated with hyperlinks is to follow the link. Activation requests are typically initiated by users through an input device.</p>
+ <p>Event targets may have associated <em>activation behavior</em> that implementations perform in response to an <em>activation request</em>. As an example, the typical activiation behavior associated with hyperlinks is to follow the link. Activation requests are typically initiated by users through an input device.</p>
<p>In terms of this specification, the activation behavior of the event target is the default action of the event type <a href="#events-event-DOMActivate">DOMActivate</a>. DOM applications should use this event type whenever they wish to make or react to an activation request.</p>
<p>Implementations dispatch the <code>DOMActivate</code> event as default action of a <a href="#events-event-click">click</a> event. This click event is either part of the activation request (e.g., a user requests activiation using a mouse), or synthesized by the implementation to accomodate legacy applications. Context information of such a <code>click</code> event is implementation dependent.</p>
<p>When implementations dispatch a synthesized <code>click</code> event, the expectation is that they do so as default action of another event type. For example, when a user activates a hyperlink using a keyboard, the <code>click</code> event would be dispatched as default action of the respective keyboard event.</p>
@@ -687,7 +707,7 @@
<div class="div2">
<a name="events-Event-types" id="events-Event-types"> </a>
<h2 id="events-Event-types-h2" class="div2">1.5 Event types</h2>
- <p>Each event is associated with a type, called <i>event type</i>. The event type is composed of a <a href="#glossary-dt-localname">local name</a> and a <a href="#glossary-dt-namespaceURI">namespace URI</a> as used in [<cite>
+ <p>Each event is associated with a type, called <em>event type</em>. The event type is composed of a <a href="#glossary-dt-localname">local name</a> and a <a href="#glossary-dt-namespaceURI">namespace URI</a> as used in [<cite>
<a class="noxref normative" href="#references-DOMCore">DOM Level 3 Core</a>
</cite>]. All events defined in this specification are in no namespace.</p>
<div class="div3">
@@ -1250,9 +1270,9 @@
<h2 id="events-Events-interface-h2" class="div2">1.6 Basic interfaces</h2>
<p>The interfaces described in this section are fundamental to DOM Level 3 Events and must always be supported by the implementation. Together they define the feature Events 3.0.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-Event" id="events-Events-Event">Event</a>
- </i></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
<dd>
<p>The <code>Event</code> interface is used to provide contextual information about an event to the listener processing the event. An object which implements the <code>Event</code> interface is passed as the parameter to an <a href="#events-Events-EventListener">
<code>EventListener</code>
@@ -1305,10 +1325,10 @@
<br/>
</dd>
<dt>
- <strong>Definition group <i>
+ <strong>Definition group <em>
<a name="events-Events-Event-eventPhaseType"
id="events-Events-Event-eventPhaseType">PhaseType</a>
- </i></strong>
+ </em></strong>
</dt>
<dd>
<p>An integer indicating which phase of the event flow is being processed as defined in <a href="#events-Events-flow">Event dispatch and DOM event flow</a>.</p>
@@ -1572,9 +1592,9 @@
</dd>
</dl>
</dd>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-CustomEvent" id="events-Events-CustomEvent">CustomEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
<dd>
<p>The CustomEvent interface is the recommended interface for application-specific event types. Unlike the <a href="#events-Events-Event">
<code>Event</code>
@@ -1673,9 +1693,9 @@
</dd>
</dl>
</dd>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-EventTarget" id="events-Events-EventTarget">EventTarget</a>
- </i></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
<dd>
<p>The <code>EventTarget</code> interface is implemented by all the objects which could be <a href="#glossary-dt-event-target">event targets</a> in an implementation which supports an event flow. The interface allows registration and removal of event listeners, and dispatch of events to an event target.</p>
<p>When used with the DOM event flow, this interface is implemented by all <a href="#glossary-dt-target-node">target nodes</a> and target ancestors, i.e. all DOM <code>Nodes</code> of the tree support this interface when the implementation conforms to DOM Level 3 Events and, therefore, this interface can be obtained by using binding-specific casting methods on an instance of the <code>Node</code> interface.</p>
@@ -1984,9 +2004,9 @@
</dd>
</dl>
</dd>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-EventListener" id="events-Events-EventListener">EventListener</a>
- </i></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
<dd>
<p>The <code>EventListener</code> interface is the primary way for handling events. Users implement the <code>EventListener</code> interface and register their event listener on an <a href="#events-Events-EventTarget">
<code>EventTarget</code>
@@ -2051,9 +2071,9 @@
</dd>
</dl>
</dd>
- <dt><strong>Exception <i>
+ <dt><strong>Exception <em>
<a name="events-Events-EventException" id="events-Events-EventException">EventException</a>
- </i></strong> introduced in <strong class="version">DOM Level 2</strong></dt>
+ </em></strong> introduced in <strong class="version">DOM Level 2</strong></dt>
<dd>
<p>Event operations may throw an <a href="#events-Events-EventException">
<code>EventException</code>
@@ -2079,10 +2099,10 @@
<br/>
</dd>
<dt>
- <strong>Definition group <i>
+ <strong>Definition group <em>
<a name="events-Events-EventException-EventExceptionCode"
id="events-Events-EventException-EventExceptionCode">EventExceptionCode</a>
- </i></strong>
+ </em></strong>
</dt>
<dd>
<p>An integer indicating the type of error generated.</p>
@@ -2132,9 +2152,9 @@
<code>Event</code>
</a> objects created must be known by the DOM Events implementation; otherwise an event exception is thrown.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-DocumentEvent" id="events-Events-DocumentEvent">DocumentEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
<dd>
<p>The <code>DocumentEvent</code> interface provides a mechanism by which the user can create an <a href="#events-Events-Event">
<code>Event</code>
@@ -2315,9 +2335,9 @@
<p>This module defines the feature UIEvents 3.0 and depends on the features Events 3.0 and Views 2.0.</p>
<p>The User Interface event module contains basic event types associated with user interfaces.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-UIEvent" id="events-Events-UIEvent">UIEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
<dd>
<p>The <code>UIEvent</code> interface provides specific contextual information associated with User Interface events.</p>
<p>To create an instance of the <code>UIEvent</code> interface, use the <a href="#events-Events-DocumentEvent-createEvent">
@@ -2766,9 +2786,9 @@
<a class="noxref informative" href="#references-HTML40">HTML 4.01</a>
</cite>] <code>onkeypress</code> attribute. Unlike this attribute, the event type <a href="#events-event-textInput">textInput</a> applies only to characters and is designed for use with any text input devices, not just keyboards. Refer to Appendix A, "<a href="#keyset-KeySet">Keyboard events and key identifiers</a>", for examples on how text events are used in combination with keyboard events.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-TextEvent" id="events-Events-TextEvent">TextEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
<dd>
<p>The <code>TextEvent</code> interface provides specific contextual information associated with Text Events.</p>
<p>To create an instance of the <code>TextEvent</code> interface, use the <a href="#events-Events-DocumentEvent-createEvent">
@@ -2811,7 +2831,7 @@
</code> of type <code>DOMString</code>, readonly</dt>
<dd><code>data</code> holds the value of the characters generated by the character device. This may be a single Unicode character or a non-empty sequence of Unicode characters [<cite>
<a class="noxref normative" href="#references-Unicode">Unicode</a>
- </cite>]. Characters should be normalized as defined by the Unicode normalization form <i>NFC</i>, defined in [<cite>
+ </cite>]. Characters should be normalized as defined by the Unicode normalization form <em>NFC</em>, defined in [<cite>
<a class="noxref normative" href="#references-UnicodeNormalization">UAX #15</a>
</cite>]. This attribute cannot be null or contain the empty string.<br/></dd>
</dl>
@@ -2984,7 +3004,7 @@
</a> are in use.</td>
</tr>
</table>
-One or more characters have been entered. The characters can originate from a variety of sources. For example, it could be characters resulting from a key being pressed or released on a keyboard device, characters resulting from the processing of an <a href="#keyset-dt-ime">input method editor</a>, or resulting from a voice command. Where a "paste" operation generates a simple sequence of characters, i.e. a text without any structure or style information, this event type should be generated as well.</dd>
+One or more characters have been entered. The characters can originate from a variety of sources. For example, it could be characters resulting from a key being pressed or released on a keyboard device, characters resulting from the processing of an <a href="#glossary-dt-ime">input method editor</a>, or resulting from a voice command. Where a "paste" operation generates a simple sequence of characters, i.e. a text without any structure or style information, this event type should be generated as well.</dd>
</dl>
</div>
</div>
@@ -2997,9 +3017,9 @@
<p>This module defines the feature KeyboardEvents 3.0 and depends on the feature UIEvents 3.0.</p>
<p>Keyboard events are device dependent, i.e. they rely on the capabilities of the input devices and how they are mapped in the operating systems. It is therefore highly recommended to rely on <a href="#events-Events-TextEvent">Text events types</a> when dealing with character input.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-KeyboardEvent" id="events-Events-KeyboardEvent">KeyboardEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
<dd>
<p>The <code>KeyboardEvent</code> interface provides specific contextual information associated with keyboard devices. Each keyboard event references a key using an identifier. Keyboard events are commonly directed at the element that has the focus.</p>
<p>The <code>KeyboardEvent</code> interface provides convenient attributes for some common modifiers keys: <a href="#events-Events-KeyboardEvent-ctrlKey">
@@ -3061,10 +3081,10 @@
<br/>
</dd>
<dt>
- <strong>Definition group <i>
+ <strong>Definition group <em>
<a name="events-ID-KeyboardEvent-KeyLocationCode"
id="events-ID-KeyboardEvent-KeyLocationCode">KeyLocationCode</a>
- </i></strong>
+ </em></strong>
</dt>
<dd>
<p>This set of constants is used to indicate the location of a key on the device. In case a DOM implementation wishes to provide a new location information, a value different from the following constant values must be used.</p>
@@ -3388,7 +3408,7 @@
</a> are in use.</td>
</tr>
</table>
-A key is pressed down. This event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type is generated after the keyboard mapping but before the processing of an <a href="#keyset-dt-ime">input method editor</a>. This event should logically happen before the event <a href="#events-event-keyup">keyup</a> is produced. Whether a <a href="#events-event-keydown">keydown</a> contributes or not to the generation of a text event is implementation dependent.</dd>
+A key is pressed down. This event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type is generated after the keyboard mapping but before the processing of an <a href="#glossary-dt-ime">input method editor</a>. This event should logically happen before the event <a href="#events-event-keyup">keyup</a> is produced. Whether a <a href="#events-event-keydown">keydown</a> contributes or not to the generation of a text event is implementation dependent.</dd>
</dl>
</div>
<div class="event-definition">
@@ -3458,7 +3478,7 @@
</a> corresponds to the key modifier itself.</td>
</tr>
</table>
-A key is released. This event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type is generated after the keyboard mapping but before the processing of an <a href="#keyset-dt-ime">input method editor</a>. This event should logically happen after the event <a href="#events-event-keydown">keydown</a> is produced. Whether a keyup contributes or not to the generation of a text event is implementation dependent.</dd>
+A key is released. This event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type is generated after the keyboard mapping but before the processing of an <a href="#glossary-dt-ime">input method editor</a>. This event should logically happen after the event <a href="#events-event-keydown">keydown</a> is produced. Whether a keyup contributes or not to the generation of a text event is implementation dependent.</dd>
</dl>
</div>
</div>
@@ -3472,9 +3492,9 @@
<a class="noxref informative" href="#references-HTML40">HTML 4.01</a>
</cite>] <code>onclick</code>, <code>ondblclick</code>, <code>onmousedown</code>, <code>onmouseup</code>, <code>onmouseover</code>, <code>onmousemove</code>, and <code>onmouseout</code> attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-MouseEvent" id="events-Events-MouseEvent">MouseEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
<dd>
<p>The <code>MouseEvent</code> interface provides specific contextual information associated with Mouse events.</p>
<p>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 their descendent elements.</p>
@@ -3830,8 +3850,7 @@
</dd>
</dl>
<p>The Mouse event types are listed below. In the case of nested elements, mouse event types are always targeted at the most deeply nested element. Ancestors of the targeted element may use bubbling to obtain notification of mouse events which occur within its descendent elements.</p>
- <p><a name="events-dt-current-click-count" id="events-dt-current-click-count"
- /> Implementations must maintain the <i>current click count</i> when generating mouse events. This is a non-negative integer indicating the number of consecutive clicks of a pointing device button during a user action. The notion of consecutive clicks depends on the environment configuration. For example, a "double click" might not happen if there is a long delay between the two clicks.</p>
+ <p><a name="events-dt-current-click-count" id="events-dt-current-click-count"/> Implementations must maintain the <em>current click count</em> when generating mouse events. This is a non-negative integer indicating the number of consecutive clicks of a pointing device button during a user action. The notion of consecutive clicks depends on the environment configuration. For example, a "double click" might not happen if there is a long delay between the two clicks.</p>
<div class="event-definition">
<dl>
<dt>
@@ -4371,9 +4390,9 @@
<p>Mouse wheel events are a subset of mouse multi wheel events. See <a href='#events-Events-eventgroupings-wheelevents'>Wheel event types</a> for additional information.</p>
-->
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-MouseWheelEvent" id="events-Events-MouseWheelEvent">MouseWheelEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
<dd>
<p>The <code>MouseWheelEvent</code> interface provides specific contextual information associated with mouse wheel events.</p>
<p>To create an instance of the <code>MouseWheelEvent</code> interface, use the <a href="#events-Events-DocumentEvent-createEvent">
@@ -4632,9 +4651,9 @@
title="ISSUE-9 - Web Applications Working Group Tracker">ISSUE-9</a>.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-WheelEvent" id="events-Events-WheelEvent">WheelEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
<dd>
<p>The <code>WheelEvent</code> interface provides specific contextual information associated with omnidirectional mouse wheel events.</p>
<p>To create an instance of the <code>WheelEvent</code> interface, use the <a href="#events-Events-DocumentEvent-createEvent">
@@ -4895,9 +4914,9 @@
<p>The mutation and mutation name event modules are designed to allow notification of any changes to the structure of a document, including attribute, text, or name modifications. It may be noted that none of the event types associated with the modules are designated as cancelable. This stems from the fact that it is very difficult to make use of existing DOM interfaces which cause document modifications if any change to the document might or might not take place due to cancelation of the resulting 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.</p>
<p>Many single modifications of the tree can cause multiple mutation events to be dispatched. Rather than attempt to specify the ordering of mutation events due to every possible modification of the tree, the ordering of these events is left to the implementation.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-MutationEvent" id="events-Events-MutationEvent">MutationEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 2</strong>)</dt>
<dd>
<p>The <code>MutationEvent</code> interface provides specific contextual information associated with Mutation events.</p>
<p>To create an instance of the <code>MutationEvent</code> interface, use the <a href="#events-Events-DocumentEvent-createEvent">
@@ -4948,10 +4967,10 @@
<br/>
</dd>
<dt>
- <strong>Definition group <i>
+ <strong>Definition group <em>
<a name="events-Events-MutationEvent-attrChangeType"
id="events-Events-MutationEvent-attrChangeType">attrChangeType</a>
- </i></strong>
+ </em></strong>
</dt>
<dd>
<p>An integer indicating in which way the <code>Attr</code> was changed.</p>
@@ -5545,9 +5564,9 @@
<h3 id="events-Events-eventgroupings-mutationnameevents-h3" class="div3">1.7.8 Mutation name event types</h3>
<p>This module defines the feature MutationNameEvents 3.0 and depends on the features MutationEvents 3.0 and Core 3.0.</p>
<dl>
- <dt><strong>Interface <i>
+ <dt><strong>Interface <em>
<a name="events-Events-MutationNameEvent" id="events-Events-MutationNameEvent">MutationNameEvent</a>
- </i></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
+ </em></strong> (introduced in <strong class="since">DOM Level 3</strong>)</dt>
<dd>
<p>The <code>MutationNameEvent</code> interface provides specific contextual information associated with Mutation name event types.</p>
<p>To create an instance of the <code>MutationNameEvent</code> interface, use the <code>Document.createEvent("MutationNameEvent")</code> method call.</p>
@@ -6416,73 +6435,46 @@
<a name="glossary-glossary" id="glossary-glossary"> </a>
<h1 id="glossary-role-glossary" class="glossary">Glossary</h1>
<dl>
- <dt><i>Editors</i>:</dt>
+ <dt><em>Editors</em>:</dt>
<dd>Doug Schepers, W3C</dd>
<dd>Arnaud Le Hors, W3C</dd>
<dd>Robert S. Sutor, IBM Research (for DOM Level 1)</dd>
</dl>
<p class="first">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.</p>
<dl id="glossary-list">
- <dt>
- <a name="glossary-dt-bubbling-phase" id="glossary-dt-bubbling-phase">bubbling phase</a>
- </dt>
- <dd>The process by which an <a href="#glossary-dt-event">event</a> can be handled by one of the target ancestors after being handled by the <a href="#glossary-dt-target-node">target node</a>.</dd>
- <dt>
- <a name="glossary-dt-capture-phase" id="glossary-dt-capture-phase">capture phase</a>
- </dt>
- <dd>The process by which an <a href="#glossary-dt-event">event</a> can be handled by one of the target ancestors before being handled by the <a href="#glossary-dt-target-node">target node</a>.</dd>
- <dt>
- <a name="glossary-dt-dead-key" id="glossary-dt-dead-key">dead key</a>
- </dt>
- <dd>A dead key is a key or combination of key that produces no character by itself, but which in combination or sequence with another key produces a modified character, such as a character with diacritical marks (e.g. <code>ö</code>, <code>é</code>, <code>â</code>).</dd>
- <dt>
- <a name="glossary-dt-DOM-Level-0" id="glossary-dt-DOM-Level-0">DOM Level 0</a>
- </dt>
- <dd>The term "DOM Level 0" refers to a mix (not formally specified) of HTML document functionalities offered by Netscape Navigator version 3.0 and Microsoft Internet Explorer version 3.0. In some cases, attributes or methods have been included for reasons of backward compatibility with "DOM Level 0".</dd>
- <dt>
- <a name="glossary-dt-event" id="glossary-dt-event">event</a>
- </dt>
- <dd>An event is the representation of some asynchronous occurrence (such as a mouse click on the presentation of the element, or the removal of child node from an element, or any of unthinkably many other possibilities) that gets associated with an <a href="#glossary-dt-event-target">event target</a>.</dd>
- <dt>
- <a name="glossary-dt-event-target" id="glossary-dt-event-target">event target</a>
- </dt>
- <dd>The object to which an <a href="#glossary-dt-event">event</a> is targeted.</dd>
- <dt>
- <a name="glossary-dt-localname" id="glossary-dt-localname">local name</a>
- </dt>
- <dd>See local name in [<cite>
- <a class="noxref informative" href="#references-Namespaces11">XML Namespaces 1.1</a>
- </cite>].</dd>
- <dt>
- <a name="glossary-dt-namespaceURI" id="glossary-dt-namespaceURI">namespace URI</a>
- </dt>
- <dd>A <i>namespace URI</i> is a URI that identifies an XML namespace. This is called the namespace name in [<cite>
- <a class="noxref informative" href="#references-Namespaces11">XML Namespaces 1.1</a>
- </cite>]. See also sections 1.3.2 "<a class="normative" href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#baseURIs-Considerations">
- <em>DOM URIs</em>
- </a>" and 1.3.3 "<a class="normative" href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations">
- <em>XML Namespaces</em>
- </a>" regarding URIs and namespace URIs handling and comparison in the DOM APIs.</dd>
- <dt>
- <a name="glossary-dt-phase" id="glossary-dt-phase">phase</a>
- </dt>
- <dd>In the context of <a href="#glossary-dt-event">events</a>, a phase is set of logical traversals from node to node along the DOM tree, from the <a href="#glossary-dt-root-element">root element</a> down to the <a href="#glossary-dt-event-target">event target</a> (<a href="glossary-dt-capture-phase">capture phase</a>), at the <a href="#glossary-dt-event-target">event target</a> itself (<a href="glossary-dt-target-phase">target phase</a>), and back up to the <a href="#glossary-dt-root-element">root element</a> (<a href="glossary-dt-bubbling-phase">bubbling phase</a>).</dd>
- <dt>
- <a name="glossary-dt-target-node" id="glossary-dt-target-node">target node</a>
- </dt>
- <dd>The target node is the node representing the <a href="#glossary-dt-event-target">event target</a> to which an <a href="#glossary-dt-event">event</a> is targeted using the DOM event flow.</dd>
- <dt>
- <a name="glossary-dt-root-element" id="glossary-dt-root-element">root element</a>
- </dt>
- <dd>The first element node of a document, of which all other elements are children; the document element.</dd>
- <dt>
- <a name="glossary-dt-target-phase" id="glossary-dt-target-phase">target phase</a>
- </dt>
- <dd>The process by which an <a href="#glossary-dt-event">event</a> can be handled by the <a href="#glossary-dt-event-target">event target</a>.</dd>
- <dt>
- <a name="glossary-dt-Unicode-character-categories" id="glossary-dt-Unicode-character-categories">Unicode character categories</a>
- </dt>
- <dd>The Unicode character categories, a subset of the complete Unicode general categories, are comprised of the categories <abbr title="Letter, Lowercase">Ll</abbr>, <abbr title="Letter, Modifier">Lm</abbr>, <abbr title="Letter, Other">Lo</abbr>, <abbr title="Letter, Titlecase">Lt</abbr>, <abbr title="Letter, Uppercase">Lu</abbr>, <abbr title="Number, Decimal Digit">Nd</abbr>, <abbr title="Number, Letter">Nl</abbr>, <abbr title="Number, Other">No</abbr>, <abbr title="Punctuation, Connector">Pc</abbr>, <abbr title="Punctuation, Dash">Pd</abbr>, <abbr title="Punctuation, Close">Pe</abbr>, <abbr title="Punctuation, Final quote">Pf</abbr>, <abbr title="Punctuation, Initial quote">Pi</abbr>, <abbr title="Punctuation, Other">Po</abbr>, <abbr title="Punctuation, Open">Ps</abbr>, <abbr title="Symbol, Currency">Sc</abbr>, <abbr title="Symbol, Modifier">Sk</abbr>, <abbr title="Symbol, Math">Sm</abbr>, and <abbr title="Symbol, Other">So</abbr>.</dd>
+ <dt id="glossary-dt-bubbling-phase">bubbling phase</dt>
+ <dd>The process by which an <a href="#glossary-dt-event">event</a> can be handled by one of the target ancestors after being handled by the <a href="#glossary-dt-target-node">target node</a>.</dd>
+ <dt id="glossary-dt-capture-phase">capture phase</dt>
+ <dd>The process by which an <a href="#glossary-dt-event">event</a> can be handled by one of the target ancestors before being handled by the <a href="#glossary-dt-target-node">target node</a>.</dd>
+ <dt id="glossary-dt-dead-key">dead key</dt>
+ <dd>A dead key is a key or combination of key that produces no character by itself, but which in combination or sequence with another key produces a modified character, such as a character with diacritical marks (e.g. <code>ö</code>, <code>é</code>, <code>â</code>).</dd>
+ <dt id="glossary-dt-dispatch">dispatch</dt>
+ <dd>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.</dd>
+ <dt id="glossary-dt-DOM-Level-0">DOM Level 0</dt>
+ <dd>The term "DOM Level 0" refers to a mix (not formally specified) of HTML document functionalities offered by Netscape Navigator version 3.0 and Microsoft Internet Explorer version 3.0. In some cases, attributes or methods have been included for reasons of backward compatibility with "DOM Level 0".</dd>
+ <dt id="glossary-dt-event">event</dt>
+ <dd>An event is the representation of some asynchronous occurrence (such as a mouse click on the presentation of the element, or the removal of child node from an element, or any of unthinkably many other possibilities) that gets associated with an <a href="#glossary-dt-event-target">event target</a>.</dd>
+ <dt id="glossary-dt-event-target">event target</dt>
+ <dd>The object to which an <a href="#glossary-dt-event">event</a> is targeted.</dd>
+ <dt id="glossary-dt-localname">local name</dt>
+ <dd>See local name in [<cite><a class="noxref informative" href="#references-Namespaces11">XML Namespaces 1.1</a></cite>].</dd>
+ <dt id="glossary-dt-ime">IME</dt>
+ <dt id="glossary-dt-input-method-editor">input method editor</dt>
+ <dd>An <em>input method editor</em> (IME), also known as a <em>front end processor</em>, is an application that performs the conversion between keystrokes and ideographs or other characters, usually by user-guided dictionary lookup, often used in East Asian languages (e.g. Chinese, Japanese, Korean). An IME may also be used for dictionary-based word completion, such as on mobile devices. See <a href="#keyset-IME">Input Method Editors</a> in Appendix A for treatment of IMEs in this specification.</dd>
+ <dt id="glossary-dt-namespaceURI">namespace URI</dt>
+ <dd>A <em>namespace URI</em> is a URI that identifies an XML namespace. This is called the namespace name in [<cite><a class="noxref informative" href="#references-Namespaces11">XML Namespaces 1.1</a></cite>]. See also sections 1.3.2 "<a class="normative" href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#baseURIs-Considerations"> <em>DOM URIs</em></a>" and 1.3.3 "<a class="normative" href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations"><em>XML Namespaces</em></a>" regarding URIs and namespace URIs handling and comparison in the DOM APIs.</dd>
+ <dt id="glossary-dt-phase">phase</dt>
+ <dd>In the context of <a href="#glossary-dt-event">events</a>, a phase is set of logical traversals from node to node along the DOM tree, from the <a href="#glossary-dt-root-element">root element</a> down to the <a href="#glossary-dt-event-target">event target</a> (<a href="glossary-dt-capture-phase">capture phase</a>), at the <a href="#glossary-dt-event-target">event target</a> itself (<a href="glossary-dt-target-phase">target phase</a>), and back up to the <a href="#glossary-dt-root-element">root element</a> (<a href="glossary-dt-bubbling-phase">bubbling phase</a>).</dd>
+ <dt id="glossary-dt-target-node">target node</dt>
+ <dd>The target node is the node representing the <a href="#glossary-dt-event-target">event target</a> to which an <a href="#glossary-dt-event">event</a> is targeted using the DOM event flow.</dd>
+ <dt id="glossary-dt-root-element">root element</dt>
+ <dd>The first element node of a document, of which all other elements are children; the document element.</dd>
+ <dt id="glossary-dt-target-phase">target phase</dt>
+ <dd>The process by which an <a href="#glossary-dt-event">event</a> can be handled by the <a href="#glossary-dt-event-target">event target</a>.</dd>
+ <dt id="glossary-dt-tree">tree</dt>
+ <dd>A data structure that represents a document as a hierarchical set of nodes with child-parent-sibling relationships, i.e. each node having one or more possible ancestors (nodes higher in the hierarchy in a direct lineage), one or more possible descendants (nodes lower in the hierarchy in a direct lineage), and one or more possible peers (nodes of the same level in the hierarchy, with the same immediate ancestor).</dd>
+ <dt id="glossary-dt-Unicode-character-categories">Unicode character categories</dt>
+ <dd>The Unicode character categories, a subset of the complete Unicode general categories, comprise the categories <abbr title="Letter, Lowercase">Ll</abbr>, <abbr title="Letter, Modifier">Lm</abbr>, <abbr title="Letter, Other">Lo</abbr>, <abbr title="Letter, Titlecase">Lt</abbr>, <abbr title="Letter, Uppercase">Lu</abbr>, <abbr title="Number, Decimal Digit">Nd</abbr>, <abbr title="Number, Letter">Nl</abbr>, <abbr title="Number, Other">No</abbr>, <abbr title="Punctuation, Connector">Pc</abbr>, <abbr title="Punctuation, Dash">Pd</abbr>, <abbr title="Punctuation, Close">Pe</abbr>, <abbr title="Punctuation, Final quote">Pf</abbr>, <abbr title="Punctuation, Initial quote">Pi</abbr>, <abbr title="Punctuation, Other">Po</abbr>, <abbr title="Punctuation, Open">Ps</abbr>, <abbr title="Symbol, Currency">Sc</abbr>, <abbr title="Symbol, Modifier">Sk</abbr>, <abbr title="Symbol, Math">Sm</abbr>, and <abbr title="Symbol, Other">So</abbr>.</dd>
</dl>
</div>
<!-- div1 glossary -->
@@ -6500,7 +6492,7 @@
<a name="keyset-KeySet" id="keyset-KeySet"> </a>
<h1 id="keyset-KeySet-h1" class="adiv1">Appendix A: Keyboard events and key identifiers</h1>
<dl>
- <dt><i>Editors</i>:</dt>
+ <dt><em>Editors</em>:</dt>
<dd>Doug Schepers, W3C</dd>
<dd><a href="http://bjoern.hoehrmann.de/">Björn Höhrmann</a> Invited Expert (until December 2007)</dd>
<dd>Philippe Le Hégaret, W3C (until November 2003)</dd>
@@ -6543,7 +6535,7 @@
<div class="div2">
<a name="keyset-KeySet-intro" id="keyset-KeySet-intro"> </a>
<h2 id="keyset-KeySet-intro-h2" class="adiv2">A.1 Introduction</h2>
- <p>Each keyboard event references a key using a <code>DOMString</code> key identifier. The set contained in this appendix is based on the sets of keycodes from:</p>
+ <p class="first">Each keyboard event references a key using a <code>DOMString</code> key identifier. The set contained in this appendix is based on the sets of keycodes from:</p>
<ul>
<li>the interface <code>java.awt.event.KeyEvent</code> of the Java 2 Platform v1.4 [<cite>
<a class="noxref informative" href="#references-KeyEvent">KeyEvent for Java</a>
@@ -6552,6 +6544,11 @@
<a class="noxref informative" href="#references-Keys">Keys enumeration for .Net</a>
</cite>].</li>
</ul>
+
+ <p>Key identifiers are strings used for uniquely addressing keyboard buttons, and intended for use in two primary scenarios: as attributes for a keyboard event; or as string values for markup attributes, such as so-called "hotkeys" (or keyboard shortcuts). As attributes on an event, the key identifier is a single canonical value. As author-generated content, the key identifier may be one of three equivalent string values, which all evaluate to the same key identifier; the string may be a character string (a single character, such as a letter or symbol), a key name (a multi-character string, such as <code>enter</code> or <code>tab</code>, for control or dead keys, or certain symbols), or a Unicode codepoint ("U+" followed by a hexadecimal character index). The event attribute will always be the most author-friendly of these, in the following order: character string, key name, or Unicode codepoint.</p>
+
+ <p>There are several use cases for keyboard events. The first use case is to retrieve the value of the key itself, in whichever mode that key currently represents (i.e. the value of a key as an upper- or lower-case letter, or a symbol or number, depending upon the current modifier keys, or as a key name); this may be used for monitoring particular input strings, or for modifier key input, or for author-generated virtual keyboards, and does not not depend upon the location of the key in the physical layout of the device, which may be mapped to different configurations based on user or system preference. The second use case is for keyboard shortcuts, where the string itself may be of secondary importance, and where they key used should default to the most appropriate key for the function, language, operating system, device, and other environmental factors (such as <code>ctrl+c</code> for copy operations). The final use case is completely independent of the value of the key identifier, and relies solely on the physical layout of the input device itself (such as for game controls); this is highly variable device-dependent functionality, and is not within the scope of this specification. Implementations should provide an option for users to establish their own preferential mapping for keyboard layout, and may rely upon ISO 9995-3, which defines a common layout for primary and secondary key mappings on a typical alphanumeric keyboard, or on ISO 9995-8, which defines a numeric keypad layout and secondary assignment of Unicode characters in the range <abbr title="a-z">U+0061..U+007A</abbr> to the number keys <code>2</code> through <code>9</code>.
+
<!--
<p>There are several primary use cases for Key Identifiers, roughly divided into cases for output and input. For output,
@@ -6605,7 +6602,7 @@
... Does not care about location, just the end value
</p>
-->
- <p class="first">While implementations are recommended to use the most relevant identifier for a key independently of the platform or keyboard layout mappings, DOM applications should not make assumption on the ability of keyboard devices to generate them. When using keyboard events, <cite>"consider using numbers and function keys (F4, F5, and so on) instead of letters in shortcut-key combinations"</cite> ([<cite>
+ <p>While implementations are recommended to use the most relevant identifier for a key independently of the platform or keyboard layout mappings, DOM applications should not make assumption on the ability of keyboard devices to generate them. When using keyboard events, <cite>"consider using numbers and function keys (F4, F5, and so on) instead of letters in shortcut-key combinations"</cite> ([<cite>
<a class="noxref informative" href="#references-DWW95">DWW95</a>
</cite>]) given that most keyboard layouts will provide keys for those.</p>
<p><code>"U+0000"</code>, <code>"U+0001"</code>, ..., <code>"U+10FFFF"</code> are Unicode based key identifiers ([<cite>
@@ -6665,7 +6662,7 @@
<a name="keyset-DeadKeys" id="keyset-DeadKeys"> </a>
<h3 id="keyset-DeadKeys-h3" class="adiv3">A.1.2 Dead keys</h3>
<p>Keyboard input uses dead keys for the input of composed character sequences. Unlike the handwriting sequence, in which users enter the base character first, keyboard input requires to enter a special state when a dead key is pressed and emit the character(s) only when one of a limited number of "legal" base character is entered.</p>
- <p>The dead keys are represented in the key identifiers set using combining diacritical marks. The sequence of keystrokes "U+0302" (Combining Circumflex Accent key) and "U+0045" (Latin Capital Letter E key) will likely produce (on a PC/AT french keyboard using a french mapping and without any modifier activated) the Unicode character ê (Latin Small Letter E With Circumflex), as preferred by the Unicode Normalization Form <i>NFC</i>:</p>
+ <p>The dead keys are represented in the key identifiers set using combining diacritical marks. The sequence of keystrokes "U+0302" (Combining Circumflex Accent key) and "U+0045" (Latin Capital Letter E key) will likely produce (on a PC/AT french keyboard using a french mapping and without any modifier activated) the Unicode character ê (Latin Small Letter E With Circumflex), as preferred by the Unicode Normalization Form <em>NFC</em>:</p>
<ol>
<li><code>"keydown"</code>: <code>"U+0302"</code> (Combining Circumflex Accent key)</li>
<li><code>"keyup"</code>: <code>"U+0302"</code></li>
@@ -6678,9 +6675,9 @@
<div class="div3">
<a name="keyset-IME" id="keyset-IME"> </a>
<h3 id="keyset-IME-h3" class="adiv3">A.1.3 Input Method Editors</h3>
- <p><a name="keyset-dt-ime" id="keyset-dt-ime"
- /> Also known as <i>front end processor</i>, an <i>input method editor</i> (IME) is an application that performs the conversion between keystrokes and ideographs or other characters, usually by user-guided dictionary lookup.</p>
- <p>This specification does not provide a representation of the input method editor (IME) events, i.e. the IME's functions and the IME context are not represented in this set. As an example, receiving a <a href="#events-event-keydown">keydown</a> for the "Accept" key identifier does not necessarily imply that the text currently selected in the IME is being accepted. It only indicates that a keystroke happened, disconnected from the IME Accept functionality. Depending on the device in use, the IME Accept functionality can be obtain using the Accept key or the Return key. Keyboard events cannot be used to determine the current state of the input method editor.</p>
+ <!-- Moved to glossary
+ <p><a name="keyset-dt-ime" id="keyset-dt-ime"/> Also known as <em>front end processor</em>, an <em>input method editor</em> (IME) is an application that performs the conversion between keystrokes and ideographs or other characters, usually by user-guided dictionary lookup.</p>-->
+ <p>This specification does not provide a representation of the <a href="#glossary-dt-ime">input method editor (IME)</a> events, i.e. the IME's functions and the IME context are not represented in this set. As an example, receiving a <a href="#events-event-keydown">keydown</a> for the "Accept" key identifier does not necessarily imply that the text currently selected in the IME is being accepted. It only indicates that a keystroke happened, disconnected from the IME Accept functionality. Depending on the device in use, the IME Accept functionality can be obtain using the Accept key or the Return key. Keyboard events cannot be used to determine the current state of the input method editor.</p>
<p>Keyboard events correspond to the events generated by the input device after the keyboard layout mapping but before the processing of the input method editor.</p>
<p>The following example describes a possible sequence of keys to generate the Unicode character 市 (Kanji character, part of CJK Unified Ideographs) using Japanese input methods. This example assumes that the input method editor is activated and in the Japanese-Romaji input mode. The keys <code>"Convert"</code> and <code>"Accept"</code> may be replaced by others depending on the input device in use and the configuration of the IME, e.g. it could be respectively "U+0020" (Space key) and "Enter".</p>
<ol>
@@ -6747,9 +6744,9 @@
<p>The list of key identifiers contained in this appendix is not exhaustive and input devices may have to define their own key identifiers. Here is a algorithm to determine which key identifier to use:</p>
<ol>
- <li> Consider the primary function of the key (i.e., without modifiers), taking into consideration the keyboard layout mapping in use, to determine if a corresponding Unicode character exists from which a key identifier may be derived. If multiple Unicode characters exist which correspond to the primary function of the key, the Unicode character with the lowest codepoint must be used.
+ <li> Consider the primary function of the key (i.e., without modifiers), taking into consideration the keyboard layout mapping in use, to determine if a corresponding Unicode character exists from which a key identifier may be derived. If multiple Unicode characters exist which correspond to the primary function of the key, the Unicode character with the lowest codepoint must be used.
<ol>
- <li> If the primary function of the key is to generate a character, and that character is in one of the <a href="#glossary-dt-Unicode-character-categories">Unicode character categories</a> for which there exists an equivalent single character in class <abbr title="Letter, Uppercase">Lu</abbr>, the uppercase character should be used instead. <span class="issue">Is this necessary? Why can't we simply allow lowercase letters as well? If a script author wishes to do a comparison, they can cast the output to upper or lower case as needed.</span></li>
+ <li> If the primary function of the key is to generate a character, and that character is in one of the <a href="#glossary-dt-Unicode-character-categories">Unicode character categories</a>, then the key identifier is a string consisting of just that character. If the primary function of the key is to generate a character in class <abbr title="Letter, Lowercase">Ll</abbr> for which there exists an equivalent, single character in class <abbr title="Letter, Uppercase">Lu</abbr>, the uppercase character should be used instead. <br/><span class="issue">Is this necessary? Why can't we simply allow lowercase letters as well? If a script author wishes to do a comparison, they can cast the output to upper or lower case as needed. See <a href="http://www.w3.org/2008/webapps/track/issues/23" title="ISSUE-23 - Web Applications Working Group Tracker">ISSUE-23</a>.</span></li>
<li> If the primary function of the key is to generate a character that is not in one of the above general categories, or if the primary function of the key is a function for which there exists a corresponding Unicode character that is not in one of the above general categories, then:
<ol>
<li>If there exists an appropriate key identifier in the <a href="#keyset-KeySet-Set">key identifiers set</a>, and that key identifier does not have a Unicode codepoint, that key identifier must be used.</li>
@@ -6763,21 +6760,124 @@
</li>
</ol>
</li>
- <li> For keys with no corresponding Unicode character, a key identifier can be devised. The key identifier should be as human friendly as possible and must not contain whitespace. The identifier must be composed only of characters in the ranges <abbr title="0-9">U+0030..U+0039</abbr>, <abbr title="A-Z">U+0041..U+005A</abbr>, or <abbr title="a-z">U+0061..U+007A</abbr>, and must begin with a character in the range <abbr title="A-Z">U+0041..U+005A</abbr>.
- <span class="issue">Why should we not allow names in other ranges (Chinese, for example)?</span></li>
+ <li> For keys with no corresponding Unicode character, a key identifier can be devised. The key identifier should be as human friendly as possible and must not contain whitespace. The identifier must be composed only of characters in the ranges <abbr title="0-9">U+0030..U+0039</abbr>, <abbr title="A-Z">U+0041..U+005A</abbr>, or <abbr title="a-z">U+0061..U+007A</abbr>, and must begin with a character in the range <abbr title="A-Z">U+0041..U+005A</abbr>. <br/><span class="issue">Why should we not allow names in other ranges (Chinese, for example)?</span></li>
</ol>
<p>Examples:</p>
<ul>
- <li> On a PC/AT US keyboard with a US keyboard mapping, the primary function (unmodified) of the 'Q' key is to generate the character U+0071. Since this character is in general category Ll, and there is a single corresponding character in Lu, U+0051, this character is used instead. Thus, the key identifier is "Q". </li>
+ <li> On a PC/AT US keyboard with a US keyboard mapping, the primary function (unmodified) of the 'Q' key is to generate the character U+0071. Since this character is in general category Ll, and there is a single corresponding character in Lu, U+0051, this character is used instead. Thus, the key identifier is "Q". <br/><span class="issue">What is the use case here? Why are uppercase letters being given priority? See <a href="http://www.w3.org/2008/webapps/track/issues/23" title="ISSUE-23 - Web Applications Working Group Tracker">ISSUE-23</a>.</span></li>
<li> On a PC/AT US keyboard with a two-handed Dvorak keyboard mapping, the 'Q' key maps to the '5/%' key. The primary function of this key is to generate the character U+0035. Since this character is in general category Nd, the key identifier is "5". </li>
<li> On a French PC keyboard with a standard French mapping, the primary function of the '^' key is as a dead key for the circumflex diacritical mark. This corresponds to the combining Unicode character U+0302. Since this character is in general category Mn, the key identifier is "U+0302". </li>
<li> On a Korean PC keyboard with a standard Korean mapping, the primary function of the 'Ha/En' key is to switch between Hangul and English input. The predefined key identifier list has an appropriate entry for this key, "HangulMode", so this is the key identifier. </li>
<li> On some models of PDAs, the primary function of the key with a picture of a calendar on it is to launch the calendaring program. Since there is no Unicode character that corresponds to this function, and there is no appropriate entry in the predefined key identifier list, an new identifier can be devised, such as "Calendar".
</li>
<ul>
+
+ <!--
+ If these are equivalent to U+0030 to U+0039 then they certainly
+ shouldn't be prefixed with Dial, since that's not appropriate for
+ computer keyboards. If you wanted to avoid the "U+...." naming scheme
+ for the key identifiers altogether, the "Guidelines for defining key
+ identifiers" section could be rewritten to achieve this. Actually, I
+ would prefer this. Currently the only requirement is that the
+ identifier not include any whitespace. I don't see any problem with
+ using the actual characters (for those keys that map to non-control
+ Unicode characters and aren't combining characters).
+
+ A.1.5 Guidelines for defining key identifiers
+
+ The list of key identifiers contained in this appendix is not
+ exhaustive and input devices may have to define their own key
+ identifiers. Here is a algorithm to determine which key identifier to
+ use:
+
+ 1. Consider the primary function of the key (i.e., without
+ modifiers), taking into consideration the keyboard layout mapping
+ in use, to determine if a corresponding Unicode character exists
+ from which a key identifier may be derived. If there exists
+ multiple Unicode characters that correspond to the primary
+ function of the key, the Unicode character with the lowest
+ codepoint must be used.
+
+ 1.1. If the primary function of the key is to generate a
+ character, and that character is in one of the Unicode
+ general categories Lu, Ll, Lt, Lm, Lo, Nd, Nl, No, Pc, Pd,
+ Ps, Pe, Pi, Pf, Po, Sm, Sc, Sk or So, then the key
+ identifier is a string consisting of just that character.
+ If the primary function of the key is to generate a
+ character in class Ll for which there exists an equivalent,
+ single character in class Lu, the uppercase character should
+ be used instead.
+
+ 1.2. If the primary function of the key is to generate a
+ character that is not in one of the above general
+ categories, or if the primary function of the key is a
+ function for which there exists a corresponding Unicode
+ character that is not in one of the above general categories, then:
+
+ 1.2.1. If there exists an appropriate key identifier in the
+ list in section A.2 below, that key identifier must
+ be used.
+
+ 1.2.2. If there is no appropriate key identifier in A.2,
+ then the key identifier is a string beginning with
+ "U+" and followed by the Unicode codepoint of the
+ character in hexadecimal, using at least four digits.
+ Leading zeroes must be omitted unless they are
+ required to make the codepoint use at least four
+ digits.
+
+ 2. For keys with no corresponding Unicode character, a key
+ identifier can be devised. The key identifier should be as human
+ friendly as possible and must not contain whitespace. The
+ identifier must be composed only of characters in the ranges
+ U+0030..U+0039, U+0041..U+005A, U+0061..U+007A and must begin
+ with a character in the range U+0041..U+005A.
+
+ Examples:
+
+ * On a PC/AT US keyboard with a US keyboard mapping, the primary
+ function (unmodified) of the 'Q' key is to generate the character
+ U+0071. Since this character is in general category Ll, and there
+ is a single corresponding character in Lu, U+0051, this character
+ is used instead. Thus, the key identifier is "Q".
+
+ * On a PC/AT US keyboard with a two-handed Dvorak keyboard mapping,
+ the 'Q' key maps to the '5/%' key. The primary function of this
+ key is to generate the character U+0035. Since this character is
+ in general category Nd, the key identifier is "5".
+
+ * On a French PC keyboard with a standard French mapping, the primary
+ function of the '^' key is as a dead key for the circumflex
+ diacritical mark. This corresponds to the combining Unicode
+ character U+0302. Since this character is in general category Mn,
+ the key identifier is "U+0302".
+
+ * On a Korean PC keyboard with a standard Korean mapping, the
+ primary function of the 'Ha/En' key is to switch between Hangul
+ and English input. The predefined key identifier list has an
+ appropriate entry for this key, "HangulMode", so this is the key
+ identifier.
+
+ * On some models of PDAs, the primary function of the key with a
+ picture of a calendar on it is to launch the calendaring program.
+ Since there is no Unicode character that corresponds to this
+ function, and there is no appropriate entry in the predefined key
+ identifier list, an new identifier can be devised, such as
+ "Calendar".
+
+ It may be a good idea to survey recent phone and PDA models and include
+ some extra key identifiers in the list to avoid different names being
+ invented for the same key.
+
+ -->
+
</div>
-<p class="issue">In the case of markup and attribute values, should the Key Identifiers for character keys be case-insensitive?</p>
+ <ul>
+ <li class="issue">Add a "power" key?</li>
+ <li class="issue">In the case of markup and attribute values, should the Key Identifiers for character keys be case-insensitive?</li>
+ </ul>
+
<!-- div3 Guide -->
</div>
<!-- div2 KeySet-intro -->
@@ -7065,10 +7165,10 @@
<dt><a name="keyset-key-RightParen" id="keyset-key-RightParen">"RightParen"</a></dt>
<dt><a name="keyset-key-U-0029" id="keyset-key-U-0029">"U+0029"</a></dt>
<dd>The Right Parenthesis (Closing Parenthesis) key ()).</dd>
- <dt><a name="keyset-key-AsterixChar" id="keyset-key-AsterixChar">"*"</a></dt>
- <dt><a name="keyset-key-Asterix" id="keyset-key-Asterix">"Asterix"</a></dt>
+ <dt><a name="keyset-key-AsteriskChar" id="keyset-key-AsteriskChar">"*"</a></dt>
+ <dt><a name="keyset-key-Asterisk" id="keyset-key-Asterisk">"Asterisk"</a></dt>
<dt><a name="keyset-key-U-002A" id="keyset-key-U-002A">"U+002A"</a></dt>
- <dd>The Asterix (Star) key (*).</dd>
+ <dd>The Asterisk (Star) key (*).</dd>
<dt><a name="keyset-key-PlusChar" id="keyset-key-PlusChar">"+"</a></dt>
<dt><a name="keyset-key-Plus" id="keyset-key-Plus">"Plus"</a></dt>
<dt><a name="keyset-key-U-002B" id="keyset-key-U-002B">"U+002B"</a></dt>
@@ -7335,7 +7435,7 @@
</tr>
<tr><th colspan="2">keydown</th><th colspan="2">keypress</th><th colspan="2">keyup</th><th colspan="2">keydown</th><th colspan="2">keypress</th><th colspan="2">keyup</th><th colspan="2">keydown</th><th colspan="2">keypress</th><th colspan="2">keyup</th><th colspan="2">keydown</th><th colspan="2">keypress</th><th colspan="2">keyup</th>
</tr>
- <tr><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th><th>keyCode</th><th>charCode</th>
+ <tr class="smallRow"><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th><th >keyCode</th><th>charCode</th>
</tr>
<tr><td> </td><td><a name="tbl-keyset-key-Accept" id="tbl-keyset-key-Accept"> Accept </a></td><td> </td><td>The Accept (Commit, OK) key.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>
</tr>
@@ -7593,7 +7693,7 @@
</tr>
<tr><td><a name="tbl-keyset-key-RightParenChar" id="tbl-keyset-key-RightParenChar"> ) </a></td><td><a name="tbl-keyset-key-RightParen" id="tbl-keyset-key-RightParen"> RightParen </a></td><td><a name="tbl-keyset-key-U-0029" id="tbl-keyset-key-U-0029"> U+0029 </a></td><td>The Right Parenthesis (Closing Parenthesis) key.</td><td>57</td><td>-</td><td>41</td><td>-</td><td>57</td><td>-</td><td>57</td><td>-</td><td>0</td><td>41</td><td>57</td><td>-</td><td>57</td><td>-</td><td>41</td><td>41</td><td>57</td><td>-</td><td>57</td><td>-</td><td>41</td><td>-</td><td>57</td><td>-</td>
</tr>
- <tr><td><a name="tbl-keyset-key-AsterixChar" id="tbl-keyset-key-AsterixChar"> * </a></td><td><a name="tbl-keyset-key-Asterix" id="tbl-keyset-key-Asterix"> Asterix </a></td><td><a name="tbl-keyset-key-U-002A" id="tbl-keyset-key-U-002A"> U+002A </a></td><td>The Asterix (Star) key (in number pad).</td><td>106</td><td>-</td><td>42</td><td>-</td><td>106</td><td>-</td><td>106</td><td>-</td><td>0</td><td>42</td><td>106</td><td>-</td><td>106</td><td>-</td><td>42</td><td>42</td><td>106</td><td>-</td><td>42</td><td>-</td><td>42</td><td>-</td><td>42</td><td>-</td>
+ <tr><td><a name="tbl-keyset-key-AsteriskChar" id="tbl-keyset-key-AsteriskChar"> * </a></td><td><a name="tbl-keyset-key-Asterisk" id="tbl-keyset-key-Asterisk"> Asterisk </a></td><td><a name="tbl-keyset-key-U-002A" id="tbl-keyset-key-U-002A"> U+002A </a></td><td>The Asterisk (Star) key (in number pad).</td><td>106</td><td>-</td><td>42</td><td>-</td><td>106</td><td>-</td><td>106</td><td>-</td><td>0</td><td>42</td><td>106</td><td>-</td><td>106</td><td>-</td><td>42</td><td>42</td><td>106</td><td>-</td><td>42</td><td>-</td><td>42</td><td>-</td><td>42</td><td>-</td>
</tr>
<tr><td><a name="tbl-keyset-key-PercentChar" id="tbl-keyset-key-PercentChar"> + </a></td><td><a name="tbl-keyset-key-Percent" id="tbl-keyset-key-Percent"> Percent </a></td><td><a name="tbl-keyset-key-U-002B" id="tbl-keyset-key-U-002B"> </a></td><td>The Percent key.</td><td>53</td><td>-</td><td>37</td><td>-</td><td>53</td><td>-</td><td>53</td><td>-</td><td>0</td><td>37</td><td>53</td><td>-</td><td>53</td><td>-</td><td>37</td><td>37</td><td>53</td><td>-</td><td>53</td><td>-</td><td>37</td><td>-</td><td>53</td><td>-</td>
</tr>
@@ -7813,7 +7913,7 @@
<a name="changes-Changes" id="changes-Changes"> </a>
<h1 id="changes-Changes-h1" class="adiv1">Appendix B: Changes</h1>
<dl>
- <dt><i>Editors</i>:</dt>
+ <dt><em>Editors</em>:</dt>
<dd>Doug Schepers, W3C</dd>
<dd><a href="http://bjoern.hoehrmann.de/">Björn Höhrmann</a> Invited Expert (until December 2007)</dd>
<dd>Philippe Le Hégaret, W3C (until November 2003)</dd>
@@ -7955,12 +8055,12 @@
<a name="security-considerations-Security" id="security-considerations-Security"> </a>
<h1 id="security-considerations-Security-h1" class="adiv1">Appendix C: Security Considerations</h1>
<dl>
- <dt><i>Editor</i>:</dt>
+ <dt><em>Editor</em>:</dt>
<dd>Doug Schepers, W3C</dd>
<dd><a href="http://bjoern.hoehrmann.de/">Björn Höhrmann</a> Invited Expert (until December 2007)</dd>
</dl>
<p class="first">This appendix discusses security considerations for DOM Level 3 Events implementations. The discussion is limited to security issues that arise directly from implementation of the event model, APIs and events defined in this specification. Implementations typically support other features like scripting languages, other APIs and additional events not defined in this document; these features constitute an unknown factor and are out of scope of this document. Implementers should consult the specifications of such features for their respective security considerations.</p>
- <p>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 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 are able to capture all user interactions and submit them to a third party through means, while not defined in DOM Level 3 Events, generally available in DOM implementations.</p>
+ <p>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 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 are able to capture all user interactions and submit them to a third party through means, while not defined in DOM Level 3 Events, generally available in DOM implementations, such as the XMLHTTPRequest interface.</p>
<p>In DOM implementations that support facilities to load external data, events like the <code>error</code> 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 then listen for <code>error</code> and <code>load</code> 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.</p>
<p>An implementation of DOM Level 3 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 example, they may choose to dispatch no <code>load</code> events to nodes that attempt to embed resources on the local network.</p>
<p>The <a href="#events-Events-DocumentEvent-canDispatch">