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

html5/webstorage Overview.html,1.163,1.164

From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 13 Apr 2011 22:10:06 +0000
To: public-html-commits@w3.org
Message-Id: <E1QA8GE-0000nc-8y@lionel-hutz.w3.org>
Update of /sources/public/html5/webstorage
In directory hutz:/tmp/cvs-serv3056

Modified Files:
	Overview.html 
Log Message:
pipeline update (whatwg r6003)

Index: Overview.html
===================================================================
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&amp;restrict=&amp;exclude=&amp;method=and&amp;format=short&amp;sort=revtime&amp;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&ouml;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:10:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 13 April 2011 22:21:46 GMT