On Dec 15, 2009, at 12:38 PM, Dmitry Titov wrote:

On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak <mjs@apple.com> wrote:

On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote:

...

On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher <darin@chromium.org> wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded.

I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading <iframe> or <script>).

If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness.

This assumes that pages are heavy I believe. The use case was about having most of the load in the shared object and pages being light UI 'frames'. This would allow to use regular URLs and history management of the browser directly. Moving most of the code and parking DOM (like editor chrome) in a shared object could enable very lightweight pages.

Regardless of how "light" the page is, a page transition is likely to be much more disruptive to user flow, particularly if the new page has to be loaded over the network and the operation takes a long time.

It sounds a bit theoretical now but the hope was that it brings interesting way of building apps in a way which could be better and perhaps simpler then building heavy non-navigatable ajax pages that have to generate content and use onbeforeunload to warn user that moving away is a bad idea :-)

I think you bundled up a lot of concepts in there that are not intrinsically tied together. You can have a page self-load new markup as HTML, insert it into itself, and update the URL and history entries with pushState, without having to do a full page load. Having no page load and replacing only the things you want to change seems better to me than having a full page load but somehow trying to save code and data across it. Regards, Maciej