[html5] r3894 - [e] (0) Optimise parser a bit (and remove some ambiguity). Bail on intros for We [...]

whatwg at whatwg.org whatwg at whatwg.org
Fri Sep 18 01:24:20 PDT 2009


Author: ianh
Date: 2009-09-18 01:24:19 -0700 (Fri, 18 Sep 2009)
New Revision: 3894

Modified:
   index
   source
Log:
[e] (0) Optimise parser a bit (and remove some ambiguity). Bail on intros for WebSocket and MessagePort for now. Other cleanup.

Modified: index
===================================================================
--- index	2009-09-18 08:15:46 UTC (rev 3893)
+++ index	2009-09-18 08:24:19 UTC (rev 3894)
@@ -855,11 +855,10 @@
      <li><a href=#posting-messages-with-message-ports><span class=secno>8.2.4 </span>Posting messages with message ports</a></ol></li>
    <li><a href=#channel-messaging><span class=secno>8.3 </span>Channel messaging</a>
     <ol>
-     <li><a href=#introduction-6><span class=secno>8.3.1 </span>Introduction</a></li>
-     <li><a href=#message-channels><span class=secno>8.3.2 </span>Message channels</a></li>
-     <li><a href=#message-ports><span class=secno>8.3.3 </span>Message ports</a>
+     <li><a href=#message-channels><span class=secno>8.3.1 </span>Message channels</a></li>
+     <li><a href=#message-ports><span class=secno>8.3.2 </span>Message ports</a>
       <ol>
-       <li><a href=#ports-and-garbage-collection><span class=secno>8.3.3.1 </span>Ports and garbage collection</a></ol></ol></ol></li>
+       <li><a href=#ports-and-garbage-collection><span class=secno>8.3.2.1 </span>Ports and garbage collection</a></ol></ol></ol></li>
  <li><a href=#syntax><span class=secno>9 </span>The HTML syntax</a>
   <ol>
    <li><a href=#writing><span class=secno>9.1 </span>Writing HTML documents</a>
@@ -984,10 +983,10 @@
    <li><a href=#parsing-xhtml-fragments><span class=secno>10.4 </span>Parsing XHTML fragments</a></ol></li>
  <li><a href=#rendering><span class=secno>11 </span>Rendering</a>
   <ol>
-   <li><a href=#introduction-7><span class=secno>11.1 </span>Introduction</a></li>
+   <li><a href=#introduction-6><span class=secno>11.1 </span>Introduction</a></li>
    <li><a href=#the-css-user-agent-style-sheet-and-presentational-hints><span class=secno>11.2 </span>The CSS user agent style sheet and presentational hints</a>
     <ol>
-     <li><a href=#introduction-8><span class=secno>11.2.1 </span>Introduction</a></li>
+     <li><a href=#introduction-7><span class=secno>11.2.1 </span>Introduction</a></li>
      <li><a href=#display-types><span class=secno>11.2.2 </span>Display types</a></li>
      <li><a href=#margins-and-padding><span class=secno>11.2.3 </span>Margins and padding</a></li>
      <li><a href=#alignment><span class=secno>11.2.4 </span>Alignment</a></li>
@@ -1005,7 +1004,7 @@
      <li><a href=#tool-bars-0><span class=secno>11.3.5 </span>Tool bars</a></ol></li>
    <li><a href=#bindings><span class=secno>11.4 </span>Bindings</a>
     <ol>
-     <li><a href=#introduction-9><span class=secno>11.4.1 </span>Introduction</a></li>
+     <li><a href=#introduction-8><span class=secno>11.4.1 </span>Introduction</a></li>
      <li><a href=#the-button-element-0><span class=secno>11.4.2 </span>The <code>button</code> element</a></li>
      <li><a href=#the-details-element-0><span class=secno>11.4.3 </span>The <code>details</code> element</a></li>
      <li><a href=#the-input-element-as-a-text-entry-widget><span class=secno>11.4.4 </span>The <code>input</code> element as a text entry widget</a></li>
@@ -60420,7 +60419,7 @@
   third steps and the penultimate step, are identical to those in the
   previous section.</p>
 
-  <!-- XXX merge this section and the previous section when
+  <!-- v2: we can merge this section and the previous section when
   implementations have shipped postMessage(). Anne asked that these
   sections be kept separate so that implementors can avoid getting
   confused with the 'port' step. -->
@@ -60431,17 +60430,8 @@
 
   <h3 id=channel-messaging><span class=secno>8.3 </span><dfn>Channel messaging</dfn></h3>
 
-  <h4 id=introduction-6><span class=secno>8.3.1 </span>Introduction</h4>
+  <h4 id=message-channels><span class=secno>8.3.1 </span>Message channels</h4>
 
-  <p><i>This section is non-normative.</i></p>
-
-  <p class=XXX>An introduction to the channel and port
-  APIs.</p>
-
-
-
-  <h4 id=message-channels><span class=secno>8.3.2 </span>Message channels</h4>
-
   <pre class=idl>[<a href=#dom-messagechannel title=dom-MessageChannel>Constructor</a>]
 interface <dfn id=messagechannel>MessageChannel</dfn> {
   readonly attribute <a href=#messageport>MessagePort</a> <a href=#dom-channel-port1 title=dom-channel-port1>port1</a>;
@@ -60509,7 +60499,7 @@
 
 
 
-  <h4 id=message-ports><span class=secno>8.3.3 </span>Message ports</h4>
+  <h4 id=message-ports><span class=secno>8.3.2 </span>Message ports</h4>
 
   <p>Each channel has two message ports. Data sent through one port is
   received by the other port, and vice versa.</p>
@@ -60797,7 +60787,7 @@
   </div>
 
 
-  <h5 id=ports-and-garbage-collection><span class=secno>8.3.3.1 </span>Ports and garbage collection</h5>
+  <h5 id=ports-and-garbage-collection><span class=secno>8.3.2.1 </span>Ports and garbage collection</h5>
 
   <div class=impl>
 
@@ -60830,8 +60820,8 @@
   <!-- we might not need to explicitly say the first part if DOM
   Events is fixed to say that events on a task queue prevent GC -->
 
-  <!-- XXX what about ports in the ports attribute of a MessageEvent
-  that isn't dispatched yet? -->
+  <!-- ports in the ports attribute of a MessageEvent that isn't
+  dispatched yet are safe because the MessageEvent is safe -->
 
   </div>
 
@@ -62484,9 +62474,7 @@
    that to break out of the <noscript> but it doesn't. This is an edge
    case that doesn't affect the spec, since the algorithm for fragment
    parsing is only used for innerHTML/outerHTML/insertAdjacentHTML(),
-   where we know scripting is enabled. (XXX except maybe if innerHTML
-   is set from another browsing context on a document with designMode
-   set?) -->
+   where we know scripting is enabled. -->
 
    <li>If <var title="">node</var> is a <code><a href=#the-body-element-0>body</a></code> element,
    then switch the <a href=#insertion-mode>insertion mode</a> to "<a href=#parsing-main-inbody title="insertion mode: in body">in body</a>" and abort these
@@ -62497,13 +62485,15 @@
    these steps. (<a href=#fragment-case>fragment case</a>)</li>
 
    <li>If <var title="">node</var> is an <code><a href=#the-html-element-0>html</a></code> element,
-   then: if the <a href=#head-element-pointer><code title="">head</code> element
-   pointer</a> is null, switch the <a href=#insertion-mode>insertion mode</a> to
-   "<a href=#the-before-head-insertion-mode title="insertion mode: before head">before head</a>",
-   otherwise, switch the <a href=#insertion-mode>insertion mode</a> to "<a href=#the-after-head-insertion-mode title="insertion mode: after head">after head</a>". In either
-   case, abort these steps. (<a href=#fragment-case>fragment case</a>)</li> <!-- XXX
-   can the head element pointer ever be non-null when we're going
-   through these steps? -->
+   then <!--: if the <span><code title="">head</code> element
+   pointer</span> is null,--> switch the <a href=#insertion-mode>insertion mode</a>
+   to "<a href=#the-before-head-insertion-mode title="insertion mode: before head">before
+   head</a>"<!--, otherwise, switch the <span>insertion mode</span>
+   to "<span title="insertion mode: after head">after head</span>".-->
+   Then, <!-- in either case, --> abort these steps. (<a href=#fragment-case>fragment
+   case</a>)</li> <!-- if the head element pointer can ever be
+   non-null when we're going through these steps, we'll need to
+   uncomment out the commented-out bits -->
 
    <li>If <var title="">last</var> is true, then switch the
    <a href=#insertion-mode>insertion mode</a> to "<a href=#parsing-main-inbody title="insertion mode: in
@@ -71066,7 +71056,7 @@
   lead to this experience.</i></p>
 
 
-  <h3 id=introduction-7><span class=secno>11.1 </span>Introduction</h3>
+  <h3 id=introduction-6><span class=secno>11.1 </span>Introduction</h3>
 
   <p>In general, user agents are expected to support CSS, and many of
   the suggestions in this section are expressed in CSS terms. User
@@ -71104,7 +71094,7 @@
 
   <h3 id=the-css-user-agent-style-sheet-and-presentational-hints><span class=secno>11.2 </span>The CSS user agent style sheet and presentational hints</h3>
 
-  <h4 id=introduction-8><span class=secno>11.2.1 </span>Introduction</h4>
+  <h4 id=introduction-7><span class=secno>11.2.1 </span>Introduction</h4>
 
   <p>The CSS rules given in these subsections are, unless otherwise
   specified, expected to be used as part of the user-agent level style
@@ -72276,7 +72266,7 @@
 
   <h3 id=bindings><span class=secno>11.4 </span>Bindings</h3>
 
-  <h4 id=introduction-9><span class=secno>11.4.1 </span>Introduction</h4>
+  <h4 id=introduction-8><span class=secno>11.4.1 </span>Introduction</h4>
 
   <p>A number of elements have their rendering defined in terms of the
   'binding' property. <a href=#refsBECSS>[BECSS]</a></p>

Modified: source
===================================================================
--- source	2009-09-18 08:15:46 UTC (rev 3893)
+++ source	2009-09-18 08:24:19 UTC (rev 3894)
@@ -72589,11 +72589,10 @@
   implement an IRC client without proxying messages through a custom
   server.</p>
 
-  <p class="XXX">An introduction to the client-side and
-  server-side of using the direct connection APIs.</p>
 
   <!--BOILERPLATE middle-w3c-api-intro-->
 
+
   <h4>The <code>WebSocket</code> interface</h4>
 
   <pre class="idl">[<span title="dom-WebSocket">Constructor</span>(in DOMString url, optional in DOMString protocol)]
@@ -74002,7 +74001,7 @@
 
   <h5>Server-side requirements</h5>
 
-  <p><i>This section only applies to servers.</i></p> <!-- XXX that's not a defined conformance class -->
+  <p><i>This section only applies to servers.</i></p>
 
   <h6>Minimal handshake</h6>
 
@@ -74833,7 +74832,7 @@
   third steps and the penultimate step, are identical to those in the
   previous section.</p>
 
-  <!-- XXX merge this section and the previous section when
+  <!-- v2: we can merge this section and the previous section when
   implementations have shipped postMessage(). Anne asked that these
   sections be kept separate so that implementors can avoid getting
   confused with the 'port' step. -->
@@ -74844,15 +74843,6 @@
 
   <h3><dfn>Channel messaging</dfn></h3>
 
-  <h4>Introduction</h4>
-
-  <p><i>This section is non-normative.</i></p>
-
-  <p class="XXX">An introduction to the channel and port
-  APIs.</p>
-
-
-
   <h4>Message channels</h4>
 
   <pre class="idl">[<span title="dom-MessageChannel">Constructor</span>]
@@ -75317,8 +75307,8 @@
   <!-- we might not need to explicitly say the first part if DOM
   Events is fixed to say that events on a task queue prevent GC -->
 
-  <!-- XXX what about ports in the ports attribute of a MessageEvent
-  that isn't dispatched yet? -->
+  <!-- ports in the ports attribute of a MessageEvent that isn't
+  dispatched yet are safe because the MessageEvent is safe -->
 
   </div>
 
@@ -77199,9 +77189,7 @@
    that to break out of the <noscript> but it doesn't. This is an edge
    case that doesn't affect the spec, since the algorithm for fragment
    parsing is only used for innerHTML/outerHTML/insertAdjacentHTML(),
-   where we know scripting is enabled. (XXX except maybe if innerHTML
-   is set from another browsing context on a document with designMode
-   set?) -->
+   where we know scripting is enabled. -->
 
    <li>If <var title="">node</var> is a <code>body</code> element,
    then switch the <span>insertion mode</span> to "<span
@@ -77214,14 +77202,15 @@
    these steps. (<span>fragment case</span>)</li>
 
    <li>If <var title="">node</var> is an <code>html</code> element,
-   then: if the <span><code title="">head</code> element
-   pointer</span> is null, switch the <span>insertion mode</span> to
-   "<span title="insertion mode: before head">before head</span>",
-   otherwise, switch the <span>insertion mode</span> to "<span
-   title="insertion mode: after head">after head</span>". In either
-   case, abort these steps. (<span>fragment case</span>)</li> <!-- XXX
-   can the head element pointer ever be non-null when we're going
-   through these steps? -->
+   then <!--: if the <span><code title="">head</code> element
+   pointer</span> is null,--> switch the <span>insertion mode</span>
+   to "<span title="insertion mode: before head">before
+   head</span>"<!--, otherwise, switch the <span>insertion mode</span>
+   to "<span title="insertion mode: after head">after head</span>".-->
+   Then, <!-- in either case, --> abort these steps. (<span>fragment
+   case</span>)</li> <!-- if the head element pointer can ever be
+   non-null when we're going through these steps, we'll need to
+   uncomment out the commented-out bits -->
 
    <li>If <var title="">last</var> is true, then switch the
    <span>insertion mode</span> to "<span title="insertion mode: in




More information about the Commit-Watchers mailing list