- From: poot <cvsmail@w3.org>
- Date: Wed, 13 Apr 2011 18:23:27 -0400
- To: public-html-diffs@w3.org
webstorage; hixie: pipeline update (whatwg r6003)
http://dev.w3.org/cvsweb/html5/webstorage/Overview.html?r1=1.163&r2=1.164&f=h
http://html5.org/tools/web-apps-tracker?from=6002&to=6003
===================================================================
RCS file: /sources/public/html5/webstorage/Overview.html,v
retrieving revision 1.163
retrieving revision 1.164
diff -u -d -r1.163 -r1.164
--- Overview.html 12 Apr 2011 00:10:38 -0000 1.163
+++ Overview.html 13 Apr 2011 22:10:04 -0000 1.164
@@ -1,7 +1,4 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"><!-- when publishing, change bits marked ZZZ
- ZZZ: Set PUB to 1 for TR/ drafts, 0 for dev drafts; PUB-Y lines are used if it's 1 and PUB-N lines if it's 0.
- ZZZ: Set YEAR, SHORTDAY (month/day), and LONGDAY accordingly. They are used by the INSERT FOO bits below.
- --><html lang="en-US-x-Hixie"><title>Web Storage</title><style type="text/css">
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"><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; }
@@ -229,12 +226,11 @@
<p><a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72"></a></p>
<h1>Web Storage</h1>
- <h2 class="no-num no-toc" id="editor-s-draft-12-april-2011">Editor's Draft 12 April 2011</h2>
+ <h2 class="no-num no-toc" id="editor-s-draft-13-april-2011">Editor's Draft 13 April 2011</h2>
<dl><dt>Latest Published Version:</dt>
<dd><a href="http://www.w3.org/TR/webstorage/">http://www.w3.org/TR/webstorage/</a></dd>
<dt>Latest Editor's Draft:</dt>
<dd><a class="latest-link" href="http://dev.w3.org/html5/webstorage/">http://dev.w3.org/html5/webstorage/</a></dd>
-<!-- ZZZ: add the new version after it has shipped-->
<dt>Previous Versions:</dt>
<dd><a href="http://www.w3.org/TR/2011/WD-webstorage-20110208/">http://www.w3.org/TR/2011/WD-webstorage-20110208/</a></dd>
<dd><a href="http://www.w3.org/TR/2009/WD-webstorage-20091222/">http://www.w3.org/TR/2009/WD-webstorage-20091222/</a></dd>
@@ -262,12 +258,12 @@
</div><hr class="top"><h2 class="no-num no-toc" id="abstract">Abstract</h2><p>This specification defines an API for persistent data storage of
- key-value pair data in Web clients.<h2 class="no-num no-toc" id="status-of-this-document">Status of This document</h2><!-- intro boilerplate (required) --><p><em>This section describes the status of this document at the
+ key-value pair data in Web clients.<h2 class="no-num no-toc" id="status-of-this-document">Status of This document</h2><p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the most recently
formally published revision of this technical report can be found in
the <a href="http://www.w3.org/TR/">W3C technical reports index</a>
- at http://www.w3.org/TR/.</em></p><!-- where to send feedback (required) --><p>If you wish to make comments regarding this document in a manner
+ at http://www.w3.org/TR/.</em></p><p>If you wish to make comments regarding this document in a manner
that is tracked by the W3C, please submit them via using <a href="http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG">our
public bug database</a>. If you do not have an account then you can
enter feedback using this form:<form action="http://www.whatwg.org/specs/web-apps/current-work/file-spam.cgi" method="post">
@@ -305,14 +301,14 @@
<a href="http://lists.w3.org/Archives/Public/public-webapps/">archives</a>),
or <a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a> (<a href="http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org">subscribe</a>,
<a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/">archives</a>).
- All feedback is welcome.</p><!-- stability (required) --><p>Implementors should be aware that this specification is not
+ All feedback is welcome.</p><p>Implementors should be aware that this specification is not
stable. <strong>Implementors who are not taking part in the
discussions are likely to find the specification changing out from
under them in incompatible ways.</strong> Vendors interested in
implementing this specification before it eventually reaches the
Candidate Recommendation stage should join the aforementioned
mailing lists and take part in the discussions.<div id="multipage-common">
- </div><!-- version history or list of changes (required) --><p>The latest
+ </div><p>The latest
stable version of the editor's draft of this specification is always
available on <a href="http://dev.w3.org/html5/webstorage/">the W3C CVS server</a>
and in the <a href="http://svn.whatwg.org/webapps/">WHATWG
@@ -331,8 +327,8 @@
</dl><p>The W3C <a href="http://www.w3.org/2008/webapps/">Web Applications
Working Group</a> is the W3C working group responsible for this
specification's progress along the W3C Recommendation track.
- This specification is the 12 April 2011 Editor's Draft.
- </p><!-- required patent boilerplate --><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
+ This specification is the 13 April 2011 Editor's Draft.
+ </p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42538/status" rel="disclosure">public list of
any patent disclosures</a> made in connection with the deliverables
of the group; that page also includes instructions for disclosing a
@@ -349,7 +345,6 @@
e-mails (as well as <a href="http://lists.whatwg.org/mmsearch.cgi/whatwg-whatwg.org?config=whatwg-whatwg.org&restrict=&exclude=&method=and&format=short&sort=revtime&words=storage+mutex">numerous others</a>):<ul><li><a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html</a></li>
<li><a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024277.html">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024277.html</a></li>
</ul><h2 class="no-num no-toc" id="contents">Table of Contents</h2>
-<!--begin-toc-->
<ol class="toc">
<li><a href="#introduction"><span class="secno">1 </span>Introduction</a></li>
<li><a href="#conformance-requirements"><span class="secno">2 </span>Conformance requirements</a>
@@ -379,7 +374,7 @@
<li><a href="#implementation-risks"><span class="secno">7.3 </span>Implementation risks</a></ol></li>
<li><a class="no-num" href="#references">References</a></li>
<li><a class="no-num" href="#acknowledgements">Acknowledgements</a></ol>
-<!--end-toc--><hr><h2 id="introduction"><span class="secno">1 </span>Introduction</h2><p><i>This section is non-normative.</i><p>This specification introduces two related mechanisms, similar to
+<hr><h2 id="introduction"><span class="secno">1 </span>Introduction</h2><p><i>This section is non-normative.</i><p>This specification introduces two related mechanisms, similar to
HTTP session cookies, for storing structured data on the client
side. <a href="#refsCOOKIES">[COOKIES]</a><p>The first is designed for scenarios where the user is carrying
out a single transaction, but could be carrying out multiple
@@ -391,8 +386,7 @@
one window to the other, potentially causing the user to buy two
tickets for the same flight without really noticing.<p>To address this, this specification introduces the <code title="dom-sessionStorage"><a href="#dom-sessionstorage">sessionStorage</a></code> IDL attribute.
Sites can add data to the session storage, and it will be accessible
- to any page from the same site opened in that window.</p><!-- we're
- not using xrefs here because this is just an intro --><div class="example">
+ to any page from the same site opened in that window.</p><div class="example">
<p>For example, a page could have a checkbox that the user ticks to
indicate that he wants insurance:</p>
@@ -410,19 +404,7 @@
<p>If the user had multiple windows opened on the site, each one
would have its own individual copy of the session storage object.</p>
- </div><!--
-
- sessionStorage.flightDeparture = 'OSL';
- sessionStorage.flightArrival = 'NYC';
-
- for (var i in forms[0].elements)
- sessionStorage["data_" + i.name] = i.value;
-
- if (!sessionStorage[documents])
- sessionStorage[documents] = {};
- sessionStorage[documents][filename] = <document/>;
-
- --><p>The second storage mechanism is designed for storage that spans
+ </div><p>The second storage mechanism is designed for storage that spans
multiple windows, and lasts beyond the current session. In
particular, Web applications may wish to store megabytes of user
data, such as entire user-authored documents or a user's mailbox, on
@@ -448,8 +430,7 @@
</div><p>Each site has its own separate storage area.<h2 id="conformance-requirements"><span class="secno">2 </span>Conformance requirements</h2><p>All diagrams, examples, and notes in this specification are
non-normative, as are all sections explicitly marked non-normative.
- Everything else in this specification is normative.<p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL
- NOT",--> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ Everything else in this specification is normative.<p>The key words "MUST", "MUST NOT", "REQUIRED", "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
@@ -511,13 +492,7 @@
setter creator void <a href="#dom-storage-setitem" title="dom-Storage-setItem">setItem</a>(in DOMString key, in any value);
deleter void <a href="#dom-storage-removeitem" title="dom-Storage-removeItem">removeItem</a>(in DOMString key);
void <a href="#dom-storage-clear" title="dom-Storage-clear">clear</a>();
-};</pre><!-- v2 ideas:
- a getInfo() method that returns an object that tells you:
- - when the key was added
- - when the key was last modified
- - which page was the last to modify the key
- [-Mihai Sucan]
- --><p>Each <code><a href="#storage-0">Storage</a></code> object provides access to a list of
+};</pre><p>Each <code><a href="#storage-0">Storage</a></code> object provides access to a list of
key/value pairs, which are sometimes called items. Keys are
strings. Any string (including the empty string) is a valid
key. Values can be any data type supported by the <span>structured
@@ -537,11 +512,7 @@
user-agent defined, but must be consistent within an object so long
as the number of keys doesn't change. (Thus, <a href="#dom-storage-setitem" title="dom-Storage-setItem">adding</a> or <a href="#dom-storage-removeitem" title="dom-Storage-removeItem">removing</a> a key may change the
order of the keys, but merely changing the value of an existing key
- must not.) <!--The order of keys may differ between instances of the
- <code>Storage</code> interface accessing the same list. [removed for
- now for clarity, but if people ask, put it back. this is part of the
- spec.]--> If <var title="">n</var> is <!--less than zero or [can't,
- unsigned]--> greater than or equal to the number of key/value pairs
+ must not.) If <var title="">n</var> is greater than or equal to the number of key/value pairs
in the object, then this method must return null.<p>The <span>supported property names</span> on a
<code><a href="#storage-0">Storage</a></code> object are the keys of each key/value pair
currently present in the list associated with the object.<p>The <dfn id="dom-storage-getitem" title="dom-Storage-getItem"><code>getItem(<var title="">key</var>)</code></dfn> method must return a
@@ -560,11 +531,7 @@
<a href="#refsHTML">[HTML]</a>
- </p><!-- ImageData isn't supported because reading such objects is
- synchronous, and getData() is synchronous, and therefore if the
- stored data is in deep storage, it would be very painful to have a
- script grab the value and immediately try to read the image
- data. --><p>Otherwise, the user agent must then check if a key/value pair
+ </p><p>Otherwise, the user agent must then check if a key/value pair
with the given <var title="">key</var> already exists in the list
associated with the object.<p>If it does not, then a new key/value pair must be added to the
list, with the given <var title="">key</var> and with its value set
@@ -586,9 +553,7 @@
none, then the method must do nothing.<p class="note">When the <code title="dom-Storage-setItem"><a href="#dom-storage-setitem">setItem()</a></code>, <code title="dom-Storage-removeItem"><a href="#dom-storage-removeitem">removeItem()</a></code>, and <code title="dom-Storage-clear"><a href="#dom-storage-clear">clear()</a></code> methods are invoked, events
are fired on other <code>Document</code> objects that can access the
newly stored or removed data, as defined in the sections on the
- <code title="dom-sessionStorage"><a href="#dom-sessionstorage">sessionStorage</a></code> and <code title="dom-localStorage"><a href="#dom-localstorage">localStorage</a></code> attributes.</p><!--
- not normative, see the sections below for the normative statement
- --><p class="note">This specification does not require that the above
+ <code title="dom-sessionStorage"><a href="#dom-sessionstorage">sessionStorage</a></code> and <code title="dom-localStorage"><a href="#dom-localstorage">localStorage</a></code> attributes.</p><p class="note">This specification does not require that the above
methods wait until the data has been physically written to
disk. Only consistency in what different scripts accessing the same
underlying list of key/value pairs see is required.<h3 id="the-sessionstorage-attribute"><span class="secno">4.2 </span>The <code title="dom-sessionStorage"><a href="#dom-sessionstorage">sessionStorage</a></code> attribute</h3><pre class="idl">[Supplemental, NoInterfaceObject]
@@ -757,9 +722,7 @@
the user to grant a site more space. This enables sites to store
many user-created documents on the user's computer, for
instance.<p>User agents should allow users to see how much space each domain
- is using.</p><!--<p>If the storage area space limit is reached during a <code
- title="dom-Storage-setItem">setItem()</code> call, the method will
- raise an exception.</p>--><p>A mostly arbitrary limit of five megabytes per
+ is using.</p><p>A mostly arbitrary limit of five megabytes per
<span>origin</span> is recommended. Implementation feedback is
welcome and will be used to update this suggestion in the
future.<h2 id="privacy"><span class="secno">6 </span>Privacy</h2><h3 id="user-tracking"><span class="secno">6.1 </span>User tracking</h3><p>A third-party advertiser (or any entity capable of getting
@@ -803,9 +766,7 @@
risk, if the user does not fully understand the implications of
data expiration.</p>
- <!--v2 consider adding an explicit way for sites to state when
- data should expire, as in localStorage.expireData(365); -->
-
+
</dd>
<dt>Treating persistent storage as cookies</dt>
@@ -903,27 +864,15 @@
user's wishlist; or a hostile site could set a user's session
identifier to a known ID that the hostile site can then use to track
the user's actions on the victim site.<p>Thus, strictly following the <span>origin</span> model described
- in this specification is important for user security.<h2 class="no-num" id="references">References</h2><!--REFS--><p>All references are normative unless marked "Non-normative".</p><!-- Dates are only included for standards older than the Web, because the newer ones keep changing. --><dl><dt id="refsCOOKIES">[COOKIES]</dt>
- <!--
- <dd><cite><a href="http://tools.ietf.org/html/rfc2109">HTTP State
- Management Mechanism</a></cite>, D. Kristol, L. Montulli. IETF.</dd>
- <dd><cite><a href="http://tools.ietf.org/html/rfc2965">HTTP State Management
- Mechanism</a></cite>, D. Kristol, L. Montulli. IETF.</dd>
- -->
- <dd><cite><a href="http://tools.ietf.org/html/draft-ietf-httpstate-cookie">HTTP State
+ in this specification is important for user security.<h2 class="no-num" id="references">References</h2><p>All references are normative unless marked "Non-normative".</p><dl><dt id="refsCOOKIES">[COOKIES]</dt>
+ <dd><cite><a href="http://tools.ietf.org/html/draft-ietf-httpstate-cookie">HTTP State
Management Mechanism</a></cite>, A. Barth. IETF.</dd>
<dt id="refsDOMCORE">[DOMCORE]</dt>
<dd><cite><a href="http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html">Web DOM Core</a></cite>, A. van Kesteren. W3C.</dd>
<dt id="refsDOMEVENTS">[DOMEVENTS]</dt>
- <!--
- <dd><cite><a
- href="http://www.w3.org/TR/DOM-Level-3-Events/">Document Object
- Model (DOM) Level 3 Events Specification</a></cite>,
- B. Höhrmann, P. Le Hegaret, T. Pixley. W3C.</dd>
- -->
- <dd><cite><a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html">Document
+ <dd><cite><a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html">Document
Object Model (DOM) Level 3 Events Specification</a></cite>,
D. Schepers. W3C.</dd>
@@ -940,11 +889,7 @@
RFCs to Indicate Requirement Levels</a></cite>, S. Bradner. IETF.</dd>
<dt id="refsWEBIDL">[WEBIDL]</dt>
- <!--
- <dd><cite><a href="http://www.w3.org/TR/WebIDL/">Web
- IDL</a></cite>, C. McCormack. W3C.</dd>
- -->
- <dd><cite><a href="http://dev.w3.org/2006/webapi/WebIDL/">Web
+ <dd><cite><a href="http://dev.w3.org/2006/webapi/WebIDL/">Web
IDL</a></cite>, C. McCormack. W3C.</dd>
</dl><h2 class="no-num" id="acknowledgements">Acknowledgements</h2><p>For a full list of acknowledgements, please see the HTML
Received on Wednesday, 13 April 2011 22:23:29 UTC