<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't have any good use cases for allowing DOM objects. And, if history is going to be recoverable, I completely agree that we shouldn't allow that. I still think we shouldn'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's what you're already doing?)</div>
</span><br><div class="gmail_quote">On Thu, Aug 20, 2009 at 11:05 AM, Justin Lebar <span dir="ltr"><<a href="mailto:justin.lebar@gmail.com">justin.lebar@gmail.com</a>></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<<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
</div><div class="im">> 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'd have<br>
to serialize to disk. I also thought that we'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>