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

[Maciej Stachowiak]

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

>
> 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.

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

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