html5/spec Overview.html,1.1131,1.1132

Update of /sources/public/html5/spec
In directory hutz:/tmp/cvs-serv17561

Modified Files:
	Overview.html 
Log Message:
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)

Index: Overview.html
===================================================================
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:08:02 UTC