[webkit-dev] SharedScript: next steps and result of offline discussion.

[Dmitry Titov]

On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak <mjs at 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 at 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.

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 :-)

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091215/77c7861b/attachment.html>