marked canDispatch at-risk
authorschepers
Thu, 27 Aug 2009 04:35:48 +0900
changeset 142 f5f8d2b3f30d
parent 141 f31a7a15c69d
child 143 b2e617ba912b
marked canDispatch at-risk
html/DOM3-Events.html
--- a/html/DOM3-Events.html	Wed Aug 26 13:59:34 2009 +0900
+++ b/html/DOM3-Events.html	Thu Aug 27 04:35:48 2009 +0900
@@ -29,7 +29,7 @@
       }
 
       .atrisk {
-          border:1px solid gray;
+          border:1px solid red;
           color: gray;
       }
 
@@ -1277,11 +1277,11 @@
                 </dt>
                 <dd>
                   <dl>
-                    <dt><code class="method-name">
+                    <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>
                     <dd>
-                      <div class="method">Tests if the implementation can generate events of a specified type.  
+                      <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>
                         <br/><span class="issue">@@ Or what does the "implementation can generate" mean? -Olli</span>
                         
@@ -4573,7 +4573,7 @@
           <p>This module defines the feature MutationEvents 3.0 and depends on the feature Events 3.0.</p>
           <p><strong>Note:</strong>  The <code>MutationEvent</code> interface was introduced in DOM Level 2 Events, but has not yet been completely and interoperably implemented across user agents.  In addition, there have been critiques that the interface, as designed, introduces a performance and implementation challenge.  A new specification is under development with the aim of addressing the use cases that mutation events solves, but in more performant manner.  Thus, this specification describes mutation events for completeness, but deprecates the use of both the <code>MutationEvent</code> interface and the <code>MutationNameEvent</code> interface.</p>
           <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 class="issue">Note that nodes that are not in the document, such as elements freshly created, or elements removed from the DOM, shall not fire mutation events when changes.  For example, if an element is created but not yet inserted into the document, then an existing element located in the document shall be moved from its current location to be a child of the new element, there must be one mutation event, for removing the existing element from its previous location, but no event must fire for insertion of the element into the new element, regardless of any assigned mutation event listeners.</p>
+      <!-- <p class="issue">Note that nodes that are not in the document, such as elements freshly created, or elements removed from the DOM, shall not fire mutation events when changed.  For example, if an element is created but not yet inserted into the document, then an existing element located in the document shall be moved from its current location to be a child of the new element, there must be one mutation event, for removing the existing element from its previous location, but no event must fire for insertion of the element into the new element, regardless of any assigned mutation event listeners.</p>
       <p class="issue">?What happens to event listeners on an element when it is removed from the tree, or moved elsewhere in the tree?</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>
@@ -5323,7 +5323,7 @@
 	   AvK: Games
 
 	   DS: We will be unable to define location on a keyboard
-	   ... Anyone making a game, wise to have user define key makpping
+	   ... Anyone making a game, wise to have user define key mapping
 
 
 	   <Travis> access keys.
@@ -7535,10 +7535,10 @@
                   <dd>This function returns an object that implements the <strong>Event</strong> interface.<br/>
 The <strong>eventType</strong> parameter shall be a <strong>String</strong>.<br />
 This function can raise an object that implements the <strong>DOMException</strong> interface.</dd>
-                  <dt>
+                  <dt class="atrisk">
                     <strong>canDispatch(namespaceURI, type)</strong>
                   </dt>
-                  <dd>This function returns a <strong>Boolean</strong>.<br/>
+                  <dd class="atrisk">This function returns a <strong>Boolean</strong>.<br/>
 The <strong>namespaceURI</strong> parameter shall be a <strong>String</strong>.<br />
 The <strong>type</strong> parameter shall be a <strong>String</strong>.</dd>
                 </dl>