--- a/html/DOM3-Events.html Sun Sep 13 03:22:47 2009 +0900
+++ b/html/DOM3-Events.html Sun Sep 13 06:27:59 2009 +0900
@@ -42,6 +42,7 @@
.atrisk {
border:1px solid red;
+ background-color: #fff0f5;
color: gray;
}
@@ -159,7 +160,7 @@
<dl>
<dt>This version:</dt>
<dd>
- <a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.79">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.79</a>
+ <a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.80">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.80</a>
</dd>
<dt>Latest stable version:</dt>
<dd>
@@ -167,7 +168,7 @@
</dd>
<dt>Previous version:</dt>
<dd>
- <a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.78">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.78</a>
+ <a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.79">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.79</a>
</dd>
<dt>Editor's Draft:</dt>
<dd>
@@ -1007,6 +1008,8 @@
boolean <a class="noxref" href="#events-Events-EventTarget-dispatchEvent">dispatchEvent</a>(in <a class="noxref" href="#events-Events-Event">Event</a> evt)
raises(<a class="noxref" href="#events-Events-EventException">EventException</a>,
DOMException);
+
+<div class="atrisk">
// Introduced in DOM Level 3:
void <a class="noxref" href="#events-Events-EventTargetGroup-addEventListenerNS">addEventListenerNS</a>(in DOMString namespaceURI,
in DOMString type,
@@ -1017,8 +1020,9 @@
in DOMString type,
in <a class="noxref" href="#events-Events-EventListener">EventListener</a> listener,
in boolean useCapture);
-
-<div class="proposal">
+</div>
+
+<div class="atrisk">
// Introduced in DOM Level 3:
void <a class="noxref" href="#events-Events-EventTarget-listen">listen</a>(in DOMString type,
in <a class="noxref" href="#events-Events-EventListener">EventListener</a> listener);
@@ -1071,8 +1075,8 @@
</dd>
- <dt><code class="method-name"><a id="events-Events-EventTargetGroup-addEventListenerNS">addEventListenerNS</a></code> introduced in <strong class="since">DOM Level 3</strong></dt>
- <dd>
+ <dt class="atrisk"><code class="method-name"><a id="events-Events-EventTargetGroup-addEventListenerNS">addEventListenerNS</a></code> introduced in <strong class="since">DOM Level 3</strong></dt>
+ <dd class="atrisk">
<div class="method">Registers an event listener, depending on the <code>useCapture</code> parameter, on the capture phase of the DOM event flow or its target and bubbling phases.
<div class="parameters"><strong>Parameters</strong><div class="paramtable"><dl><dt><code class="parameter-name">namespaceURI</code> of type <code>DOMString</code></dt><dd>Specifies the <a href="#events-event-type-namespaceURI"><code>Event.namespaceURI</code></a> associated with the event for which the user is registering.<br /></dd><dt><code class="parameter-name">type</code> of type <code>DOMString</code></dt><dd>Refer to the <a href="#events-Events-EventTarget-addEventListener"><code>EventTarget.addEventListener()</code></a> method for a description of this parameter.<br /></dd><dt><code class="parameter-name">listener</code> of type <a href="#events-Events-EventListener"><code>EventListener</code></a></dt><dd>Refer to the <a href="#events-Events-EventTarget-addEventListener"><code>EventTarget.addEventListener()</code></a> method for a description of this parameter.<br /></dd><dt><code class="parameter-name">useCapture</code> of type <code>boolean</code></dt><dd>Refer to the <a href="#events-Events-EventTarget-addEventListener"><code>EventTarget.addEventListener()</code></a> method for a description of this parameter.<br /></dd></dl></div></div>
<!-- parameters -->
@@ -1161,8 +1165,8 @@
<!-- method -->
</dd>
- <dt><code class="method-name"><a id="events-Events-EventTargetGroup-removeEventListenerNS">removeEventListenerNS</a></code> introduced in <strong class="since">DOM Level 3</strong></dt>
- <dd>
+ <dt class="atrisk"><code class="method-name"><a id="events-Events-EventTargetGroup-removeEventListenerNS">removeEventListenerNS</a></code> introduced in <strong class="since">DOM Level 3</strong></dt>
+ <dd class="atrisk">
<div class="method">Removes an event listener. Calling <code>removeEventListenerNS</code> with arguments which do not identify any currently registered <a href="#events-Events-EventListener"><code>EventListener</code></a> on the <code>EventTarget</code> has no effect.
<div class="parameters"><strong>Parameters</strong><div class="paramtable"><dl><dt><code class="parameter-name">namespaceURI</code> of type <code>DOMString</code></dt><dd>Specifies the <a href="#events-event-type-namespaceURI"><code>Event.namespaceURI</code></a> associated with the event for which the user registered the event listener.<br /></dd><dt><code class="parameter-name">type</code> of type <code>DOMString</code></dt><dd>Refer to the <a href="#events-Events-EventTarget-removeEventListener"><code>EventTarget.removeEventListener()</code></a> method for a description of this parameter.<br /></dd><dt><code class="parameter-name">listener</code> of type <a href="#events-Events-EventListener"><code>EventListener</code></a></dt><dd>Refer to the <a href="#events-Events-EventTarget-removeEventListener"><code>EventTarget.removeEventListener()</code></a> method for a description of this parameter.<br /></dd><dt><code class="parameter-name">useCapture</code> of type <code>boolean</code></dt><dd>Refer to the <a href="#events-Events-EventTarget-removeEventListener"><code>EventTarget.removeEventListener()</code></a> method for a description of this parameter.<br /></dd></dl></div></div>
<!-- parameters -->
@@ -1352,7 +1356,7 @@
</dt>
<dd>
<dl>
- <dt><code class="method-name atrisk"><a id="events-Events-DocumentEvent-canDispatch">canDispatch</a></code> introduced in <strong class="since">DOM Level 3</strong></dt>
+ <dt class="atrisk"><code class="method-name"><a id="events-Events-DocumentEvent-canDispatch">canDispatch</a></code> introduced in <strong class="since">DOM Level 3</strong></dt>
<dd>
<div class="method atrisk">Tests if the implementation can generate events of a specified type.
<br /><span class="issue">@@ what is the use case for this? Perhaps to test if an implementation supports a particular event, such as an event from an uncommon language, or a custom event?</span>
@@ -6025,17 +6029,21 @@
</code>
</pre>
</div>
- <h2 class="adiv2"><a id="extending_events-Namespaced_Events" href="#extending_events-Namespaced_Events">A.3 Namespaced Events</a></h2>
- <p>This specification introduces namespaces into the event model, in order to allow expansion of the set of events in a manner that doesn't introduce potential conflicts.</p>
- <h3 class="adiv2"><a id="extending_events-Legacy_Events" href="#extending_events-Legacy_Events">A.3.1 Legacy Events</a></h3>
- <p>An existing implementation which is being adapted to work with the W3C DOM Events specifications may have an existing framework and set of proprietary events. For backwards compatibility, it may be desirable that such an implementation keep these existing events, while providing the means for them to work within the DOM Events framework. In this case, the implementer can simply assign their own vendor-specific namespace to these proprietary events.</p>
- <p>In some cases, these legacy events may conflict with other implementation-specific events with the same name, but different functionality. Using the namespace-aware method <a href="#events-Events-EventTargetGroup-addEventListenerNS"><code>EventTarget.addEventListenerNS()</code></a>, an author can target that event specifically, with no risk of clashes.</p>
- <p>When there are no known conflicting events, or when such events have the same functionality, the author can simply use the non-namespace-aware method <a href="#events-Events-EventTarget-addEventListener"><code>EventTarget.addEventListener()</code></a>, which can register events without regard to the namespace.</p>
- <p class="example">As an example, a particular browser vendor, "FooCorp", may have an event, "skip", which was implemented long ago, and which also works with another FooCorp product. They need to keep this event for backwards compatibility with existing content for some of their clients, but since this event is very specific to their product lines, they don't anticipate that it will be of general use in competing browsers. This vendor implements "skip" in their browser, using their namespace, <code class="value">'http://example.com/foo/browser/events/'</code>. Their event continues to work using their existing event registration system, and also works with W3C DOM Events methods, both <code>someElement.addEventListener( "skip", doSkip, false )</code> and <code>someElement.addEventListenerNS( "http://example.com/foo/browser/events/", "skip", doSkip, false )</code>. Other browsers simply ignore this event, and legacy content continues to work in the FooCorp browser.</p>
- <h3 class="adiv2"><a id="extending_events-Vendor_Extensions" href="#extending_events-Vendor_Extensions">A.3.2 Vendor Extensions</a></h3>
- <p>While a new event is being designed and prototyped, or when an event is intended for implementation-specific functionality, it is desirable to distinguish it from standardized events. In CSS, the mechanism for doing this is to provide <a href="http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords" title="Syntax and basic data types">vendor-specific keyword prefixes</a>; however, this has the unfortunate side-effect of forcing authors to maintain code that may be identical between vendors, but which nevertheless must retain the prefix.</p>
- <p>In DOM Events, by using namespaces for vendor-specific events, an author can choose either to target a particular snapshot of an implementation-specific event by using the namespace-aware method <a href="#events-Events-EventTargetGroup-addEventListenerNS"><code>EventTarget.addEventListenerNS()</code></a>, or to write code that assumes broader future implementation by using the non-namespace-aware method <a href="#events-Events-EventTarget-addEventListener"><code>EventTarget.addEventListener()</code></a>.</p>
- <p class="example">As an example, a particular browser vendor, "FooCorp", may wish to introduce a new event, "jump". This vendor implements "jump" in their browser, using their namespace, <code class="value">'http://example.com/foo/browser/events/'</code>. Early adopters start experimenting with the event, using <code>someElement.addEventListenerNS( "http://example.com/foo/browser/events/", "jump", doJump, false )</code>, and provide feedback to FooCorp, who change the behavior of "jump" accordingly. After some time, another vendor, "BarOrg", decides they also want the functionality, but implement it slightly differently, so they use their own namespace, <code class="value">'http://example.org/bar/browser/events/'</code> but with the same event type, "jump". Authors experimenting with this version of "jump" register events with BarOrg's namespace. Authors who wish to write code that accounts for both browsers can either register each event type separately with specific handlers, or use the same handler and switch on the namespace of the event; thus, early experiments in different codebases do not conflict, and the easrly-adopter is able to write easily-maintained code for multiple implementations. Eventually, as the feature matures, the behavior of both browsers stabilizes and may converge due to author and user feedback or through formal standardization; as this stabilization occurs, and risk of conflicts decrease, authors can remove the forked code, and assume the "jump" event is in the <code>null</code> namespace (even before it is formally standardized), using the same event handler and the more generic registration method <code>someElement.addEventListener( "jump", doJump, false )</code>.</p>
+
+ <br />
+ <div class="atrisk">
+ <h2 class="adiv2"><a id="extending_events-Namespaced_Events" href="#extending_events-Namespaced_Events">A.3 Namespaced Events</a></h2>
+ <p>This specification introduces namespaces into the event model, in order to allow expansion of the set of events in a manner that doesn't introduce potential conflicts.</p>
+ <h3 class="adiv2"><a id="extending_events-Legacy_Events" href="#extending_events-Legacy_Events">A.3.1 Legacy Events</a></h3>
+ <p>An existing implementation which is being adapted to work with the W3C DOM Events specifications may have an existing framework and set of proprietary events. For backwards compatibility, it may be desirable that such an implementation keep these existing events, while providing the means for them to work within the DOM Events framework. In this case, the implementer can simply assign their own vendor-specific namespace to these proprietary events.</p>
+ <p>In some cases, these legacy events may conflict with other implementation-specific events with the same name, but different functionality. Using the namespace-aware method <a href="#events-Events-EventTargetGroup-addEventListenerNS"><code>EventTarget.addEventListenerNS()</code></a>, an author can target that event specifically, with no risk of clashes.</p>
+ <p>When there are no known conflicting events, or when such events have the same functionality, the author can simply use the non-namespace-aware method <a href="#events-Events-EventTarget-addEventListener"><code>EventTarget.addEventListener()</code></a>, which can register events without regard to the namespace.</p>
+ <p class="example">As an example, a particular browser vendor, "FooCorp", may have an event, "skip", which was implemented long ago, and which also works with another FooCorp product. They need to keep this event for backwards compatibility with existing content for some of their clients, but since this event is very specific to their product lines, they don't anticipate that it will be of general use in competing browsers. This vendor implements "skip" in their browser, using their namespace, <code class="value">'http://example.com/foo/browser/events/'</code>. Their event continues to work using their existing event registration system, and also works with W3C DOM Events methods, both <code>someElement.addEventListener( "skip", doSkip, false )</code> and <code>someElement.addEventListenerNS( "http://example.com/foo/browser/events/", "skip", doSkip, false )</code>. Other browsers simply ignore this event, and legacy content continues to work in the FooCorp browser.</p>
+ <h3 class="adiv2"><a id="extending_events-Vendor_Extensions" href="#extending_events-Vendor_Extensions">A.3.2 Vendor Extensions</a></h3>
+ <p>While a new event is being designed and prototyped, or when an event is intended for implementation-specific functionality, it is desirable to distinguish it from standardized events. In CSS, the mechanism for doing this is to provide <a href="http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords" title="Syntax and basic data types">vendor-specific keyword prefixes</a>; however, this has the unfortunate side-effect of forcing authors to maintain code that may be identical between vendors, but which nevertheless must retain the prefix.</p>
+ <p>In DOM Events, by using namespaces for vendor-specific events, an author can choose either to target a particular snapshot of an implementation-specific event by using the namespace-aware method <a href="#events-Events-EventTargetGroup-addEventListenerNS"><code>EventTarget.addEventListenerNS()</code></a>, or to write code that assumes broader future implementation by using the non-namespace-aware method <a href="#events-Events-EventTarget-addEventListener"><code>EventTarget.addEventListener()</code></a>.</p>
+ <p class="example">As an example, a particular browser vendor, "FooCorp", may wish to introduce a new event, "jump". This vendor implements "jump" in their browser, using their namespace, <code class="value">'http://example.com/foo/browser/events/'</code>. Early adopters start experimenting with the event, using <code>someElement.addEventListenerNS( "http://example.com/foo/browser/events/", "jump", doJump, false )</code>, and provide feedback to FooCorp, who change the behavior of "jump" accordingly. After some time, another vendor, "BarOrg", decides they also want the functionality, but implement it slightly differently, so they use their own namespace, <code class="value">'http://example.org/bar/browser/events/'</code> but with the same event type, "jump". Authors experimenting with this version of "jump" register events with BarOrg's namespace. Authors who wish to write code that accounts for both browsers can either register each event type separately with specific handlers, or use the same handler and switch on the namespace of the event; thus, early experiments in different codebases do not conflict, and the easrly-adopter is able to write easily-maintained code for multiple implementations. Eventually, as the feature matures, the behavior of both browsers stabilizes and may converge due to author and user feedback or through formal standardization; as this stabilization occurs, and risk of conflicts decrease, authors can remove the forked code, and assume the "jump" event is in the <code>null</code> namespace (even before it is formally standardized), using the same event handler and the more generic registration method <code>someElement.addEventListener( "jump", doJump, false )</code>.</p>
+ </div>
</div>
<!-- div1 Events -->
<div class="div1">