[html5] r1941 - [] (0) Remove localName from the case quirkyness since IE doesn't support it any [...]

[whatwg at whatwg.org]

Author: ianh
Date: 2008-07-25 14:06:53 -0700 (Fri, 25 Jul 2008)
New Revision: 1941

Modified:
   index
   source
Log:
[] (0) Remove localName from the case quirkyness since IE doesn't support it anyway. Remove some redundant or inappropriate requirements, editorial notes that no longer apply, and editorial fixes. (credit: hs)

Modified: index
===================================================================
--- index	2008-07-25 18:28:49 UTC (rev 1940)
+++ index	2008-07-25 21:06:53 UTC (rev 1941)
@@ -2089,7 +2089,7 @@
    faster. These systems are also significantly more complicated to specify,
    and are orders of magnitude more difficult to achieve interoperability
    with, than the solutions described in this document. Platform-specific
-   solutions for such sophisticated applications (for example the MacOS X
+   solutions for such sophisticated applications (for example the Mac OS X
    Core APIs) are even further ahead.
 
   <h3 id=relationships><span class=secno>1.3 </span>Relationships to other
@@ -2814,11 +2814,7 @@
   <p>Some elements are defined in terms of their DOM <dfn
    id=textcontent><code>textContent</code></dfn> attribute. This is an
    attribute defined on the <code>Node</code> interface in DOM3 Core. <a
-   href="#refsDOM3CORE">[DOM3CORE]</a>
-
-  <p class=big-issue>Should textContent be defined differently for dir="" and
-   <bdo>? Should we come up with an alternative to textContent that
-   handles those and other things, like alt=""?</p>
+   href="#refsDOM3CORE">[DOM3CORE]</a></p>
   <!-- This section is currently here exclusively so that we crossref
   to textContent. XXX also add event-click, event-change,
   event-DOMActivate, etc, here, once DOM3 Events is ready for that,
@@ -7336,11 +7332,7 @@
    having an attribute in the per-element partition with the name <code
    title="">class</code> containing a space-separated list of classes to
    which the element belongs. Other specifications may also allow elements in
-   their namespaces to be labeled as being in specific classes. UAs must not
-   assume that all attributes of the name <code title="">class</code> for
-   elements in any namespace work in this way, however, and must not assume
-   that such attributes, when used as global attributes, label other elements
-   as being in specific classes.
+   their namespaces to be labeled as being in specific classes.
 
   <div class=example>
    <p>Given the following XHTML fragment:</p>
@@ -8432,8 +8424,8 @@
    despite being in <a href="#html-">HTML documents</a>.
 
   <dl>
-   <dt><code title="">Element.tagName</code>, <code
-    title="">Node.nodeName</code>, and <code title="">Node.localName</code>
+   <dt><code title="">Element.tagName</code> and <code
+    title="">Node.nodeName</code>
 
    <dd>
     <p>These attributes must return element names <a
@@ -54370,14 +54362,16 @@
 
 <input type="text" menu="foo" icon="g.png"/> <menu id="foo"> <menuitem icon="g.png" onclick="engine('yahoo')">Yahoo</menuitem> ... </menu>
 
-> One more aspect I want you think about - for "user interface systems" in
-> general: The windowing system.
->   Different kinds of windows ("document", "browser (file-system/network or
-> otherwise)", "palette", "application modal dialog", "system modal dialog"),
-> the rules for layering them (appropriately flexible to allow different
-> implementations, e.g. MacOS vs. X-Windows), and simplifications for handheld
-> devices (which are sometimes single window devices anyway, but sometimes
-> they are one "normal" window plus sometimes one "dialog" window on top.
+> One more aspect I want you think about - for "user interface
+> systems" in general: The windowing system.
+>
+> Different kinds of windows ("document", "browser
+> (file-system/network or otherwise)", "palette", "application modal
+> dialog", "system modal dialog"), the rules for layering them
+> (appropriately flexible to allow different implementations, e.g. Mac
+> OS X vs. X-Windows), and simplifications for handheld devices (which
+> are sometimes single window devices anyway, but sometimes they are
+> one "normal" window plus sometimes one "dialog" window on top.
 
 window.open for dialogs
 

Modified: source
===================================================================
--- source	2008-07-25 18:28:49 UTC (rev 1940)
+++ source	2008-07-25 21:06:53 UTC (rev 1941)
@@ -87,7 +87,7 @@
   complicated to specify, and are orders of magnitude more difficult
   to achieve interoperability with, than the solutions described in
   this document. Platform-specific solutions for such sophisticated
-  applications (for example the MacOS X Core APIs) are even further
+  applications (for example the Mac OS X Core APIs) are even further
   ahead.</p>
 
 
@@ -898,10 +898,6 @@
   defined on the <code>Node</code> interface in DOM3 Core. <a
   href="#refsDOM3CORE">[DOM3CORE]</a></p>
 
-  <p class="big-issue">Should textContent be defined differently for
-  dir="" and <bdo>? Should we come up with an alternative to
-  textContent that handles those and other things, like alt=""?</p>
-
   <!-- This section is currently here exclusively so that we crossref
   to textContent. XXX also add event-click, event-change,
   event-DOMActivate, etc, here, once DOM3 Events is ready for that,
@@ -5372,11 +5368,7 @@
   <code title="">class</code> containing a space-separated list of
   classes to which the element belongs. Other specifications may also
   allow elements in their namespaces to be labeled as being in
-  specific classes. UAs must not assume that all attributes of the
-  name <code title="">class</code> for elements in any namespace work
-  in this way, however, and must not assume that such attributes, when
-  used as global attributes, label other elements as being in specific
-  classes.</p>
+  specific classes.</p>
 
   <div class="example">
 
@@ -6448,9 +6440,8 @@
 
   <dl>
 
-   <dt><code title="">Element.tagName</code>, <code
-   title="">Node.nodeName</code>, and <code
-   title="">Node.localName</code></dt>
+   <dt><code title="">Element.tagName</code> and <code
+   title="">Node.nodeName</code></dt>
 
    <dd>
 
@@ -49375,14 +49366,16 @@
 
 <input type="text" menu="foo" icon="g.png"/> <menu id="foo"> <menuitem icon="g.png" onclick="engine('yahoo')">Yahoo</menuitem> ... </menu>
 
-> One more aspect I want you think about - for "user interface systems" in
-> general: The windowing system.
->   Different kinds of windows ("document", "browser (file-system/network or
-> otherwise)", "palette", "application modal dialog", "system modal dialog"),
-> the rules for layering them (appropriately flexible to allow different
-> implementations, e.g. MacOS vs. X-Windows), and simplifications for handheld
-> devices (which are sometimes single window devices anyway, but sometimes
-> they are one "normal" window plus sometimes one "dialog" window on top.
+> One more aspect I want you think about - for "user interface
+> systems" in general: The windowing system.
+>
+> Different kinds of windows ("document", "browser
+> (file-system/network or otherwise)", "palette", "application modal
+> dialog", "system modal dialog"), the rules for layering them
+> (appropriately flexible to allow different implementations, e.g. Mac
+> OS X vs. X-Windows), and simplifications for handheld devices (which
+> are sometimes single window devices anyway, but sometimes they are
+> one "normal" window plus sometimes one "dialog" window on top.
 
 window.open for dialogs