HTML Standard Tracker

Filter

File a bug

SVNBugCommentTime (UTC)
4099Make a 'complete' spec of all the bits that WHATWG has worked on.2009-10-09 06:53
@@ -1,10 +1,11 @@
+<!--START complete-->
 <!--START html5-->
 
   <h3 class="no-num no-toc">Stability</h3>
 
   <p>Different parts of this specification are at different levels of
   maturity.</p>
 
   <div id="stability"></div>
 
 
@@ -50120,47 +50121,48 @@ document.body.appendChild(outer);</pre>
 
   </dl> 
 
   </div>
 
 
 <!--END html5-->
 
   <h3>Microdata vocabularies</h3>
 
-<!--START vocabs-->
+<!--START vocabs--><!--END complete-->
 
   <h3 class="no-num no-toc">Table of contents</h3>
   <!--toc-->
   <hr>
 
   <h4>Introduction</h4>
 
-  <p>This specification defines microdata vocabularies. <a
-  href="#refsHTML5">[HTML5]</a></p>
+  <p>This specification defines microdata vocabularies.
+  <a href="#refsHTML5">[HTML5]</a></p>
 
+<!--START complete-->
 
   <h4>vCard</h4>
 
-<!--END vocabs-->
+<!--END vocabs--><!--END complete-->
 <!--START vCard-->
 
   <h4 class="no-num no-toc">Table of contents</h4>
   <!--toc-->
   <hr>
 
   <h5>The vocabulary</h5>
 
   <p>This section defines a microdata vocabulary. <a
   href="#refsHTML5">[HTML5]</a></p>
 
-<!--START vocabs-->
+<!--START vocabs--><!--START complete-->
 
   <p>An item with the <span>item type</span> <dfn
   title="md-vcard"><code>http://microformats.org/profile/hcard</code></dfn>
   represents a person's or organization's contact information.</p>
 
   <p>The following are the type's <span title="defined property
   name">defined property names</span>. They are based on the
   vocabulary defined in the vCard specification and its extensions,
   where more information on how to interpret the values can be
   found. <a href="#refsRFC2426">[RFC2426]</a> <a
@@ -52389,32 +52391,32 @@ FN:George Washington
 N:Washington;George;;;
 END:VCARD</pre>
 
   </div>
 
 <!--END vCard-->
 
   <h4>vEvent</h4>
 
 <!--END vocabs-->
-<!--START vEvent-->
+<!--START vEvent--><!--END complete-->
 
   <h4 class="no-num no-toc">Table of contents</h4>
   <!--toc-->
   <hr>
 
   <h5>The vocabulary</h5>
 
   <p>This section defines a microdata vocabulary. <a
   href="#refsHTML5">[HTML5]</a></p>
 
-<!--START vocabs-->
+<!--START vocabs--><!--START complete-->
 
   <p>An item with the <span>item type</span> <dfn
   title="md-vevent"><code>http://microformats.org/profile/hcalendar#vevent</code></dfn>
   represents an event.</p>
 
   <p>The following are the type's <span title="defined property
   name">defined property names</span>. They are based on the
   vocabulary defined in the iCalendar specification, where more
   information on how to interpret the values can be found. <a
   href="#refsRFC2445">[RFC2445]</a></p>
@@ -53360,33 +53362,33 @@ END:VCARD</pre>
        itemprop="url">See this event on livebrum.co.uk&lt;/a>.&lt;/p>
  &lt;meta itemprop="description" content="via livebrum.co.uk">
 &lt;/div></pre>
 
   </div>
 
 <!--END vEvent-->
 
   <h4>Licensing works</h4>
 
-<!--END vocabs-->
+<!--END vocabs--><!--END complete-->
 <!--START work-->
 
   <h4 class="no-num no-toc">Table of contents</h4>
   <!--toc-->
   <hr>
 
   <h5>The vocabulary</h5>
 
   <p>This section defines a microdata vocabulary. <a
   href="#refsHTML5">[HTML5]</a></p>
 
-<!--START vocabs-->
+<!--START vocabs--><!--START complete-->
 
   <p>An item with the <span>item type</span> <dfn
   title="md-work"><code>http://n.whatwg.org/work</code></dfn>
   represents a work (e.g. an article, an image, a video, a song,
   etc). This type is primarily intended to allow authors to include
   licensing information for works.</p>
 
   <p>The following are the type's <span title="defined property
   name">defined property names</span>.</p>
 
@@ -63278,23 +63280,24 @@ NETWORK:
     localStorage.pageLoadCount = 0;
   localStorage.pageLoadCount += 1;
   document.getElementById('count').textContent = localStorage.pageLoadCount;
 &lt;/script></pre>
 
   </div>
 
   <p>Each site has its own separate storage area.</p>
 
 
-
+<!--END complete-->
   <!--BOILERPLATE middle-w3c-api-intro-->
   <!--BOILERPLATE middle-w3c-js-disclaimer-->
+<!--START complete-->
 
 
   <h4 id="storage">The API</h4>
 
   <h5>The <code>Storage</code> interface</h5>
 
   <pre class="idl">interface <dfn>Storage</dfn> {
   readonly attribute unsigned long <span title="dom-Storage-length">length</span>;
   getter any <span title="dom-Storage-key">key</span>(in unsigned long index);
   getter any <span title="dom-Storage-getItem">getItem</span>(in DOMString key);
@@ -63768,23 +63771,24 @@ prepareDatabase(function(db) {
   var q = "";
   for each (var i in labels)
     q += (q == "" ? "" : ", ") + "?";
   db.readTransaction(function (t) {
     t.executeSql('SELECT id FROM docs WHERE label IN (' + q + ')', labels, function (t, data) {
       resultCallback(data);
     });
   });
 }</pre>
 
-
+<!--END complete-->
   <!--BOILERPLATE middle-w3c-api-intro-->
   <!--BOILERPLATE middle-w3c-js-disclaimer-->
+<!--START complete-->
 
   <h4 id="sql">The API</h4>
 
   <h5>Databases</h5>
 
   <p>Each <i>origin</i> has an associated set of databases. Each
   database has a name and a current version. There is no way to
   enumerate or delete the databases available for an origin from this
   API.</p>
 
@@ -71278,24 +71282,24 @@ v2 (well, really v0):
 
   <pre>EXAMPLE workers/crypto/libcrypto-v2-decryptor.js</pre>
 
   <p>Notice how the users of the API don't have to even know that this
   is happening &mdash; the API hasn't changed; the library can
   delegate to subworkers without changing its API, even though it is
   accepting data using message channels.</p>
 
   <p><a href="http://www.whatwg.org/demos/workers/crypto/page.html">View this example online</a>.</p>
 
-
+<!--END complete-->
   <!--BOILERPLATE middle-w3c-api-intro-->
   <!--BOILERPLATE middle-w3c-js-disclaimer-->
-
+<!--START complete-->
 
   <h3>Infrastructure</h3>
 
   <p>There are two kinds of workers; dedicated workers, and shared
   workers. Dedicated workers, once created, and are linked to their
   creator; but message ports can be used to communicate from a
   dedicated worker to multiple other browsing contexts or
   workers. Shared workers, on the other hand, are named, and once
   created any script running in the same <span>origin</span> can
   obtain a reference to that worker and communicate with it.</p>
@@ -71451,22 +71455,22 @@ interface <dfn>SharedWorkerGlobalScope</dfn> : <span>WorkerGlobalScope</span> {
     <tr><th><span title="event handlers">Event handler</span> <th><span>Event handler event type</span>
    <tbody>
     <tr><td><dfn title="handler-SharedWorkerGlobalScope-onconnect"><code>onconnect</code></dfn> <td> <code title="event-connect">connect</code>
   </table>
 
   <p>For the purposes of the <span>offline application cache</span>
   networking model, a shared worker is its own <span>cache
   host</span>. The <span>run a worker</span> algorithm takes care of
   associating the worker with an <span>application cache</span>.</p>
 
-  <p class="note">The <dfn
-  title="dom-SharedWorkerGlobalScope-applicationCache"><code>applicationCache</code></dfn>
+  <p class="note">The <code
+  title="dom-SharedWorkerGlobalScope-applicationCache">applicationCache</code>
   attribute returns the <code>ApplicationCache</code> object for the
   worker.</p><!-- normative conf criteria is in the appcache section
   -->
 
 
   <h4>Origins of workers</h4>
 
   <p>Both the <span>origin</span> and <span>effective script
   origin</span> of scripts running in workers are the
   <span>origin</span> of the <span>absolute URL</span> given in that
@@ -72871,23 +72875,23 @@ source.onmessage = function (event) {
   following form, with the <code>text/event-stream</code> MIME
   type:</p>
 
   <pre>data: This is the first message.
 
 data: This is the second message, it
 data: has two lines.
 
 data: This is the third message.</pre>
 
-
+<!--END complete-->
   <!--BOILERPLATE middle-w3c-api-intro-->
-
+<!--START complete-->
 
   <h4>The <code>EventSource</code> interface</h4>
 
   <pre class="idl">[<span title="dom-EventSource">Constructor</span>(in DOMString url)]
 interface <dfn>EventSource</dfn> {
   readonly attribute DOMString <span title="dom-EventSource-URL">URL</span>;
 
   // ready state
   const unsigned short <span title="dom-EventSource-CONNECTING">CONNECTING</span> = 0;
   const unsigned short <span title="dom-EventSource-OPEN">OPEN</span> = 1;
@@ -73544,21 +73548,21 @@ data:&nbsp;test</pre>
   reference from the <code>Window</code> or <code>WorkerUtils</code>
   object that the <code>EventSource</code> object's constructor was
   invoked from to the <code>EventSource</code> object itself.</p>
 
   <p>If an <code>EventSource</code> object is garbage collected while
   its connection is still open, the connection must be closed.</p>
 
 
   <h4>IANA considerations</h4>
 
-  <h3><dfn><code>text/event-stream</code></dfn></h3>
+  <h5><dfn><code>text/event-stream</code></dfn></h5>
 
   <p>This registration is for community review and will be submitted
   to the IESG for review, approval, and registration with IANA.</p>
 
   <!--
    To: ietf-types@iana.org
    Subject: Registration of media type text/event-stream
   -->
 
   <dl>
@@ -73627,21 +73631,21 @@ data:&nbsp;test</pre>
    <dt>Author:</dt>
    <dd>Ian Hickson &lt;ian@hixie.ch></dd>
    <dt>Change controller:</dt>
    <dd>W3C</dd>
   </dl>
 
   <p>Fragment identifiers have no meaning with
   <code>text/event-stream</code> resources.</p>
 
 
-  <h3><dfn title="http-last-event-id"><code>Last-Event-ID</code></dfn></h3>
+  <h5><dfn title="http-last-event-id"><code>Last-Event-ID</code></dfn></h5>
 
   <p>This section describes a header field for registration in the
   Permanent Message Header Field Registry.  <a
   href="#refsRFC3864">[RFC3864]</a></p>
 
   <dl>
    <dt>Header field name</dt>
    <dd>Last-Event-ID</dd>
    <dt>Applicable protocol</dt>
    <dd>http</dd>
@@ -73669,23 +73673,23 @@ data:&nbsp;test</pre>
 
   <p>To enable Web applications to maintain bidirectional
   communications with server-side processes, this specification
   introduces the <code>WebSocket</code> interface.</p>
 
   <p class="note">This interface does not allow for raw access to the
   underlying network. For example, this interface could not be used to
   implement an IRC client without proxying messages through a custom
   server.</p>
 
-
+<!--END complete-->
   <!--BOILERPLATE middle-w3c-api-intro-->
-
+<!--START complete-->
 
   <h4>The <code>WebSocket</code> interface</h4>
 
   <pre class="idl">[<span title="dom-WebSocket">Constructor</span>(in DOMString url, in optional DOMString protocol)]
 interface <dfn>WebSocket</dfn> {
   readonly attribute DOMString <span title="dom-WebSocket-URL">URL</span>;
 
   // ready state
   const unsigned short <span title="dom-WebSocket-CONNECTING">CONNECTING</span> = 0;
   const unsigned short <span title="dom-WebSocket-OPEN">OPEN</span> = 1;
@@ -73965,21 +73969,25 @@ interface <dfn>WebSocket</dfn> {
    <li>The client-side script is forced to maintain a mapping from the
    outgoing connections to the incoming connection to track
    replies.</li>
 
   </ul>
 
   <p>A simpler solution would be to use a single TCP connection for
   traffic in both directions. This is what the Web Socket protocol
   provides. Combined with the Web Socket API, it provides an
   alternative to HTTP polling for two-way communication from a Web
-  page to a remote server. <a href="#refsWSAPI">[WSAPI]</a></p>
+  page to a remote server.
+  <!--END complete-->
+  <a href="#refsWSAPI">[WSAPI]</a>
+  <!--START complete-->
+  </p>
 
   <p>The same technique can be used for a variety of Web applications:
   games, stock tickers, multiuser applications with simultaneous
   editing, user interfaces exposing server-side services in real time,
   etc.</p>
 
 
 
   <h6>Protocol overview</h6>
 
@@ -74120,38 +74128,39 @@ Frame type byte &lt;-------------------------------------.
   to be a regular GET request with an Upgrade offer. In relatively
   simple setups with just one IP address and a single server for all
   traffic to a single hostname, this might allow a practical way for
   systems based on the Web Socket protocol to be deployed. In more
   elaborate setups (e.g. with load balancers and multiple servers), a
   dedicated set of hosts for Web Socket connections separate from the
   HTTP servers is probably easier to manage.</p>
 
 
 
-
+<!--END complete-->
 
   <!--BOILERPLATE middle-ietf-conformance-->
 
   <h6>Terminology</h6>
 
   <p><dfn title="converted to ASCII lowercase">Converting a string to
   ASCII lowercase</dfn> means replacing all characters in the range
   U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL
   LETTER Z) with the corresponding characters in the range U+0061
   .. U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z).</p>
 
   <p>The term "URL" is used in this section in a manner consistent
   with the terminology used in HTML, namely, to denote a string that
   might or might not be a valid URI or IRI and to which certain error
   handling behaviors will be applied when the string is parsed. <a
   href="#refsHTML5">[HTML5]</a></p>
 
+<!--START complete-->
 
 
   <h5>Web Socket URLs</h5>
 
   <h6>Parsing Web Socket URLs</h6>
 
   <p>The steps to <dfn>parse a Web Socket URL's components</dfn> from
   a string <var title="">url</var> are as follows. These steps return
   either a <var title="">host</var>, a <var title="">port</var>, a
   <var title="">resource name</var>, and a <var title="">secure</var>
@@ -74463,24 +74472,30 @@ Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE=</pre>
    </li>
 
    <li>
 
     <p>If the client has any authentication information or cookies
     that would be relevant to a resource accessed over HTTP, if <var
     title="">secure</var> is false, or HTTPS, if it is true, on host
     <var title="">host</var>, port <var title="">port</var>, with <var
     title="">resource name</var> as the path (and possibly query
     parameters), then HTTP headers that would be appropriate for that
-    information should be sent at this point. <a
-    href="#refsRFC2616">[RFC2616]</a> <a
-    href="#refsRFC2109">[RFC2109]</a> <a
-    href="#refsRFC2965">[RFC2965]</a></p>
+    information should be sent at this point.
+<!--END complete-->
+    <a href="#refsRFC2616">[RFC2616]</a>
+    <a href="#refsRFC2109">[RFC2109]</a>
+    <a href="#refsRFC2965">[RFC2965]</a>
+<!--START complete--><!--END websocket-protocol-->
+    <a href="#refsHTTP">[HTTP]</a>
+    <a href="#refsCOOKIES">[COOKIES]</a>
+<!--START websocket-protocol-->
+    </p>
 
     <p>Each header must be on a line of its own (each ending with a CR
     LF sequence). For the purposes of this step, each header must not
     be split into multiple lines (despite HTTP otherwise allowing this
     with continuation lines).</p>
 
     <div class="example">
 
      <p>For example, if the server had a username and password that
      applied to <code title="">http://example.com/socket</code>, and
@@ -74800,33 +74815,38 @@ Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE=</pre>
      title="http-websocket-protocol">websocket-protocol</code>"</dt>
 
      <dd><p>If there was a <var title="">protocol</var> specified, and
      the value is not exactly equal to <var title="">protocol</var>,
      then <span>fail the Web Socket connection</span> and abort these
      steps. (If no <var title="">protocol</var> was specified, the
      header is ignored.)</p></dd>
 
 
      <dt>If the entry's name is "<code
-     title="http-setcookie2">set-cookie</code>" or "<code
+     title="http-setcookie">set-cookie</code>" or "<code
      title="http-setcookie2">set-cookie2</code>" or another
      cookie-related header name</dt>
 
      <dd><p>Handle the cookie as defined by the appropriate
      specification, with the resource being the one with the host <var
      title="">host</var>, the port <var title="">port</var>, the path
      (and possibly query parameters) <var title="">resource
      name</var>, and the scheme <code title="">http</code> if <var
      title="">secure</var> is false and <code title="">https</code> if
-     <var title="">secure</var> is true. <a
-     href="#refsRFC2109">[RFC2109]</a> <a
-     href="#refsRFC2965">[RFC2965]</a></p></dd>
+     <var title="">secure</var> is true.
+<!--END complete-->
+     <a href="#refsRFC2109">[RFC2109]</a>
+     <a href="#refsRFC2965">[RFC2965]</a>
+<!--START complete--><!--END websocket-protocol-->
+     <a href="#refsCOOKIES">[COOKIES]</a>
+<!--START websocket-protocol-->
+     </p></dd>
 
 
      <dt>Any other name</dt>
 
      <dd>Ignore it.</dd>
 
     </dl>
 
     <hr>
 <!--
@@ -74899,21 +74919,27 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
     <dl class="switch">
 
      <dt>If the entry's name is "<code
      title="">www-authenticate</code>"</dt>
 
      <dd><p>Obtain credentials in a manner consistent with the
      requirements for handling the <code>WWW-Authenticate</code>
      header in HTTP, and then close the connection (if the server has
      not already done so) and jump back to the step labeled
      <i>connect</i>, including the relevant authentication headers in
-     the new request. <a href="#refsRFC2616">[RFC2616]</a></p></dd>
+     the new request.
+<!--END complete-->
+     <a href="#refsRFC2616">[RFC2616]</a>
+<!--START complete--><!--END websocket-protocol-->
+     <a href="#refsHTTP">[HTTP]</a>
+<!--START websocket-protocol-->
+     </p></dd>
 
      <dt>Any other name</dt>
 
      <dd>Ignore it.</dd>
 
     </dl>
 
    </li>
 
    <li>
@@ -75357,21 +75383,28 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
   <dl>
 
    <dt>URI scheme name.</dt>
    <dd>ws</dd>
 
    <dt>Status.</dt>
    <dd>Permanent.</dd>
 
    <dt>URI scheme syntax.</dt>
    <dd>
-    <p>In ABNF terms using the terminals from the URI specifications: <a href="#refsRFC5234">[RFC5234]</a> <a href="#refsRFC3986">[RFC3986]</a></p>
+    <p>In ABNF terms using the terminals from the URI specifications:
+<!--END complete-->
+    <a href="#refsRFC5234">[RFC5234]</a>
+<!--START complete--><!--END websocket-protocol-->
+    <a href="#refsABNF">[ABNF]</a>
+<!--START websocket-protocol-->
+    <a href="#refsRFC3986">[RFC3986]</a>
+    </p>
     <pre>"ws" ":" hier-part [ "?" query ]</pre>
     <p>The path and query components form the resource name sent to
     the server to identify the kind of service desired. Other
     components have the meanings described in RFC3986.</p>
    </dd>
 
    <dt>URI scheme semantics.</dt>
    <dd>The only operation for this scheme is to open a connection
    using the Web Socket protocol.</dd>
 
@@ -75425,21 +75458,27 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
   <dl>
 
    <dt>URI scheme name.</dt>
    <dd>wss</dd>
 
    <dt>Status.</dt>
    <dd>Permanent.</dd>
 
    <dt>URI scheme syntax.</dt>
    <dd>
-    <p>In ABNF terms using the terminals from the URI specifications: <a href="#refsRFC5234">[RFC5234]</a> <a href="#refsRFC3986">[RFC3986]</a></p>
+    <p>In ABNF terms using the terminals from the URI specifications:
+<!--END complete-->
+    <a href="#refsRFC5234">[RFC5234]</a>
+<!--START complete--><!--END websocket-protocol-->
+    <a href="#refsABNF">[ABNF]</a>
+<!--START websocket-protocol-->
+    <a href="#refsRFC3986">[RFC3986]</a></p>
     <pre>"wss" ":" hier-part [ "?" query ]</pre>
     <p>The path and query components form the resource name sent to
     the server to identify the kind of service desired. Other
     components have the meanings described in RFC3986.</p>
    </dd>
 
    <dt>URI scheme semantics.</dt>
    <dd>The only operation for this scheme is to open a connection
    using the Web Socket protocol, encrypted using TLS.</dd>
 
@@ -93384,20 +93423,23 @@ interface <span>HTMLDocument</span> {
    <dd>(Non-normative) <cite><a
    href="http://www.turingarchive.org/browse.php/B/12">On computable
    numbers, with an application to the
    Entscheidungsproblem</a></cite>, A. Turing. In <cite>Proceedings of
    the London Mathematical Society</cite>, series 2, volume 42, pages
    230-265. London Mathematical Society, 1937.  Retrieved on
    2007-03-03.</dd>
 
    <dt id="refsCOOKIES">[COOKIES]</dt>
    <!--
+   <dd><cite><a href="http://www.ietf.org/rfc/rfc2109.txt">HTTP State
+   Management Mechanism</a></cite>, D. Kristol, L. Montulli. IETF,
+   February 1997.</dd>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc2965.txt">HTTP State Management
    Mechanism</a></cite>, D. Kristol, L. Montulli. IETF, October 2000.</dd>
    -->
    <dd><cite><a
    href="http://tools.ietf.org/html/draft-abarth-cookie">HTTP State
    Management Mechanism</a></cite>, A. Barth. IETF, August 2009.</dd>
 
    <dt id="refsCORS">[CORS]</dt>
    <!--
    <dd><cite><a href="http://www.w3.org/TR/cors/">Cross-Origin
@@ -93778,20 +93820,25 @@ interface <span>HTMLDocument</span> {
    <dt id="refsRFC3490">[RFC3490]</dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc3490.txt">Internationalizing
    Domain Names in Applications (IDNA)</a></cite>, P. Faltstrom, P. Hoffman, A.
    Costello. IETF, March 2003.</dd>
 
    <dt id="refsRFC3548">[RFC3548]</dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc3548.txt">The Base16, Base32,
    and Base64 Data Encodings</a></cite>, S. Josefsson. IETF, July
    2003.</dd>
 
+   <dt id="refsRFC3629">[RFC3629]</dt>
+   <dd><cite><a href="http://www.ietf.org/rfc/rfc3629.txt">UTF-8, a
+   transformation format of ISO 10646</a></cite>, F. Yergeau. IETF,
+   November 2003.</dd>
+
    <dt id="refsRFC3864">[RFC3864]</dt>
    <dd><cite><a
    href="http://www.ietf.org/rfc/rfc3864.txt">Registration Procedures
    for Message Header Fields</a></cite>, G. Klyne, M. Nottingham,
    J. Mogul. IETF, September 2004.</dd>
 
    <dt id="refsRFC3986">[RFC3986]</dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc3986.txt">Uniform Resource
    Identifier (URI): Generic Syntax</a></cite>, T. Berners-Lee, R. Fielding, L.
    Masinter. IETF, January 2005.</dd>
@@ -94517,20 +94564,30 @@ interface <span>HTMLDocument</span> {
   <p>Special thanks and $10,000 to David Hyatt who came up with a
   broken implementation of the <a href="#adoptionAgency">adoption
   agency algorithm</a> that the editor had to reverse engineer and fix
   before using it in the parsing section.</p>
 
   </div>
 
   <p>Thanks to the many sources that provided inspiration for the
   examples used in the specification.</p>
 
+  <!--END html5-->
+
+  <div itemscope itemtype="http://n.whatwg.org/work">
+   <p>The abstract is based on <a itemprop="work" href="http://www.flickr.com/photos/wonderlane/2986252088/">a photo</a>
+   by <a itemprop="http://creativecommons.org/ns#attributionURL" href="http://www.flickr.com/photos/wonderlane/">Wonderlane</a>.
+   (<a itemprop="license" href="http://creativecommons.org/licenses/by/2.0/">CC BY 2.0</a>)
+  </div>
+
+  <!--START html5-->
+
   <p>Thanks also to the Microsoft blogging community for some ideas,
   to the attendees of the W3C Workshop on Web Applications and
   Compound Documents for inspiration, to the #mrt crew, the #mrt.no
   crew, and the #whatwg crew, and to Pillar and Hedral for their ideas
   and support.</p>
 
   <!-- Hopefully Kam won't notice he's covered by these
   acknowledgements three times! -->
 
 <!--
@@ -94681,10 +94738,11 @@ Consistency in editorial style:
           <li><img alt="A text field with editable sections for each
           value, with a button to pop up a dialog showing a calendar or
           clock." src="sample-datetime-ui-2"></li>
           <li><img alt="A calendar grid with a clock in the upper right
           hand corner." src="sample-datetime-ui-3"></li>
 -->
 
  </body>
 </html>
 <!--END html5-->
+<!--END complete-->

|