spec/Overview.html 1.1132 1941 Remove localName from the case quirkynes

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) (whatwg
r1941)

1.3 Relationships to other specifications
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1132.html#relationships
2.2.2 Features defined in other specifications
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1132.html#features
3.6 APIs in HTML documents
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1132.html#apis-in
textContent
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1132.html#textcontent
getElementsByClassName()
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1132.html#getelementsbyclassname0
1.2 Scope
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1132.html#scope
Acknowledgements
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1132.html#acknowledgements

http://people.w3.org/mike/diffs/html5/spec/Overview.diff.html
http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.1131&r2=1.1132&f=h
http://html5.org/tools/web-apps-tracker?from=1940&to=1941

===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.1131
retrieving revision 1.1132
diff -u -d -r1.1131 -r1.1132
--- Overview.html 25 Jul 2008 18:28:53 -0000 1.1131
+++ Overview.html 25 Jul 2008 21:07:26 -0000 1.1132
@@ -2160,7 +2160,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
@@ -2885,11 +2885,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="#references">[DOM3CORE]</a>
-
-  <p class=big-issue>Should textContent be defined differently for dir="" and
-   &lt;bdo>? Should we come up with an alternative to textContent that
-   handles those and other things, like alt=""?</p>
+   href="#references">[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,
@@ -7407,11 +7403,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>
@@ -8503,8 +8495,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
@@ -54441,14 +54433,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

Received on Friday, 25 July 2008 21:11:47 UTC