W3C home > Mailing lists > Public > public-html-commits@w3.org > April 2009

html5/webstorage Overview.html,1.22,1.23

From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
Date: Sun, 19 Apr 2009 23:53:48 +0000
To: public-html-commits@w3.org
Message-Id: <E1LvgpY-0007VF-Td@lionel-hutz.w3.org>
Update of /sources/public/html5/webstorage
In directory hutz:/tmp/cvs-serv28827

Modified Files:
	Overview.html 
Log Message:
Fix links to references section. (whatwg r2971)

Index: Overview.html
===================================================================
RCS file: /sources/public/html5/webstorage/Overview.html,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -d -r1.22 -r1.23
--- Overview.html	19 Apr 2009 23:38:47 -0000	1.22
+++ Overview.html	19 Apr 2009 23:53:46 -0000	1.23
@@ -1,4 +1,4 @@
-<!DOCTYPE html><!-- when publishing, change bits marked ZZZ --><html lang=en-US-x-Hixie><meta charset=ascii><title>Web Storage</title><style type=text/css>
+<!DOCTYPE html><!-- when publishing, change bits marked ZZZ --><html lang=en-US-x-Hixie><title>Web Storage</title><style type=text/css>
    pre { margin-left: 2em; white-space: pre-wrap; }
    h2 { margin: 3em 0 1em 0; }
    h3 { margin: 2.5em 0 1em 0; }
@@ -274,7 +274,7 @@
   NOT",--> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in the normative parts of this document are to be
   interpreted as described in RFC2119. For readability, these words do
-  not appear in all uppercase letters in this specification. <a href=#refsRFC2119>[RFC2119]</a><p>Requirements phrased in the imperative as part of algorithms
+  not appear in all uppercase letters in this specification. <a href=#references>[RFC2119]</a><p>Requirements phrased in the imperative as part of algorithms
   (such as "strip any leading space characters" or "return false and
   abort these steps") are to be interpreted with the meaning of the
   key word ("must", "should", "may", etc) used in introducing the
@@ -294,7 +294,7 @@
    <dd>
 
     <p>Many fundamental concepts from HTML5 are used by this
-    specification. <a href=#refsHTML5>[HTML5]</a></p>
+    specification. <a href=#references>[HTML5]</a></p>
 
    </dd>
 
@@ -303,7 +303,7 @@
    <dd>
 
     <p>The IDL blocks in this specification use the semantics of the
-    WebIDL specification. <a href=#refsWebIDL>[WebIDL]</a></p>
+    WebIDL specification. <a href=#references>[WebIDL]</a></p>
 
    </dd>
 
@@ -314,13 +314,13 @@
   scripts in Web applications, and does not necessarily imply the
   existence of an actual <code>Document</code> object or of any other
   <code>Node</code> objects as defined in the DOM Core
-  specifications. <a href=#refsDOM3CORE>[DOM3CORE]</a><p>A DOM attribute is said to be <em>getting</em> when its value is
+  specifications. <a href=#references>[DOM3CORE]</a><p>A DOM attribute is said to be <em>getting</em> when its value is
   being retrieved (e.g. by author script), and is said to be
   <em>setting</em> when a new value is assigned to it.<p>The term "JavaScript" is used to refer to ECMA262, rather than
   the official term ECMAScript, since the term JavaScript is more
-  widely known. <a href=#refsECMA262>[ECMA262]</a><h2 id=storage><span class=secno>3 </span>Storing name/value pairs</h2><h3 id=introduction><span class=secno>3.1 </span>Introduction</h3><p><em>This section is non-normative.</em><p>This specification introduces two related mechanisms, similar to
+  widely known. <a href=#references>[ECMA262]</a><h2 id=storage><span class=secno>3 </span>Storing name/value pairs</h2><h3 id=introduction><span class=secno>3.1 </span>Introduction</h3><p><em>This section is non-normative.</em><p>This specification introduces two related mechanisms, similar to
   HTTP session cookies, for storing structured data on the client
-  side. <a href=#refsRFC2109>[RFC2109]</a> <a href=#refsRFC2965>[RFC2965]</a><p>The first is designed for scenarios where the user is carrying
+  side. <a href=#references>[RFC2109]</a> <a href=#references>[RFC2965]</a><p>The first is designed for scenarios where the user is carrying
   out a single transaction, but could be carrying out multiple
   transactions in different windows at the same time.<p>Cookies don't really handle this case well. For example, a user
   could be buying plane tickets in two different windows, using the
@@ -570,7 +570,7 @@
 };</pre><p>The <dfn id=dom-storageevent-initstorageevent title=dom-StorageEvent-initStorageEvent><code>initStorageEvent()</code></dfn>
   and <dfn id=dom-storageevent-initstorageeventns title=dom-StorageEvent-initStorageEventNS><code>initStorageEventNS()</code></dfn>
   methods must initialize the event in a manner analogous to the
-  similarly-named methods in the DOM3 Events interfaces. <a href=#refsDOM3EVENTS>[DOM3EVENTS]</a><p>The <dfn id=dom-storageevent-key title=dom-StorageEvent-key><code>key</code></dfn>
+  similarly-named methods in the DOM3 Events interfaces. <a href=#references>[DOM3EVENTS]</a><p>The <dfn id=dom-storageevent-key title=dom-StorageEvent-key><code>key</code></dfn>
   attribute represents the key being changed.<p>The <dfn id=dom-storageevent-oldvalue title=dom-StorageEvent-oldValue><code>oldValue</code></dfn>
   attribute represents the old value of the key being changed.<p>The <dfn id=dom-storageevent-newvalue title=dom-StorageEvent-newValue><code>newValue</code></dfn>
   attribute represents the new value of the key being changed.<p>The <dfn id=dom-storageevent-url title=dom-StorageEvent-url><code>url</code></dfn>
@@ -650,7 +650,7 @@
   increase the quota every five megabytes.<h3 id=parsing-and-processing-sql-statements><span class=secno>4.3 </span>Parsing and processing SQL statements</h3><p>When the user agent is to <dfn id=preprocess-the-sql-statement title="preprocess the SQL
   statement">preprocess a SQL statement</dfn> <var title="">sqlStatement</var> with an array of arguments <var title="">arguments</var>, it must run the following steps:<ol><li><p>Parse <var title="">sqlStatement</var> as a SQL statement,
    with the exception that U+003F QUESTION MARK (?) characters can be
-   used in place of SQL literals in the statement. <a href=#refsSQL>[SQL]</a></li>
+   used in place of SQL literals in the statement. <a href=#references>[SQL]</a></li>
 
    <li>
 
@@ -872,7 +872,7 @@
      of error" steps below.</li>
 
      <li><p>Execute the statement in the context of the transaction.
-     <a href=#refsSQL>[SQL]</a></p>
+     <a href=#references>[SQL]</a></p>
 
      <li><p>If the statement failed, jump to the "in case of error"
      steps below.</li>
@@ -1023,7 +1023,7 @@
    <code><a href=#sqlexception>SQLException</a></code> exception.</li>
 
    <li><p>Execute the statement in the context of the transaction.
-   <a href=#refsSQL>[SQL]</a></p>
+   <a href=#references>[SQL]</a></p>
 
    <li><p>If the statement failed, throw a <code><a href=#sqlexception>SQLException</a></code>
    exception.</li>
@@ -1214,7 +1214,7 @@
     <p>Treating persistent storage as cookies: user agents should
     present the persistent storage and database features to the user
     in a way that does not distinguish them from HTTP session
-    cookies. <a href=#refsRFC2109>[RFC2109]</a> <a href=#refsRFC2965>[RFC2965]</a></p>
+    cookies. <a href=#references>[RFC2109]</a> <a href=#references>[RFC2965]</a></p>
 
     <p>This might encourage users to view persistent storage with
     healthy suspicion.</p>
Received on Sunday, 19 April 2009 23:53:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 April 2009 23:53:59 GMT