<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">I see.  It makes more sense why you mentioned the session storage element then.  Note that there has been some discussion about whether session storage should survive crashes, but I know Safari and Chrome are currently planning to _not_ serialize it to disk.<div>

<br></div><div>I don&#39;t have any good use cases for allowing DOM objects.  And, if history is going to be recoverable, I completely agree that we shouldn&#39;t allow that.  I still think we shouldn&#39;t force app developers to serialize everything to strings.  Maybe we can just raise an exception if they try to set the history state to something unserializable?  (I guess that&#39;s what you&#39;re already doing?)</div>

</span><br><div class="gmail_quote">On Thu, Aug 20, 2009 at 11:05 AM, Justin Lebar <span dir="ltr">&lt;<a href="mailto:justin.lebar@gmail.com">justin.lebar@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow&lt;<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>&gt; wrote:<br>
</div><div class="im">&gt; but here it seems like everything can just stay in memory...right?<br>
<br>
</div><div><div></div><div class="h5">My thought was that if you had a tab open and restarted the browser,<br>
that the state objects would be there after the restart, so we&#39;d have<br>
to serialize to disk.  I also thought that we&#39;d persist this state<br>
data even after we take a Document out of memory.<br>
<br>
It might be possible to store some subset of DOM objects while still<br>
meeting those requirements, but that seems like it might be a serious<br>
can of worms.  Do you have a use case which would be facilitated by<br>
being able to store some DOM objects in this way?<br>
<br>
-Justin<br>
</div></div></blockquote></div><br>