On Dec 15, 2009, at 12:38 PM, Dmitry Titov wrote:
On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak <m...@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 <da...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
