- From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 19 Apr 2009 23:53:48 +0000
- To: public-html-commits@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 UTC