[webkit-dev] GlobalScript API.
ojan at chromium.org
Tue Sep 1 21:58:46 PDT 2009
On Tue, Sep 1, 2009 at 9:07 PM, Oliver Hunt <oliver at apple.com> wrote:
> On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:
> Thanks a lot Maciej!
> As a note to the API described in this thread: there was a proposal in
> private thread to replace the JS constructor with 4 parameters with a tag:
> instead of
> var globalScript = new webkitGlobalScript(name, url, loadHandler,
> I know this as been discussed a million times already, but this bugs me.
What if you want to load multiple scripts or populate a globalscript from
the parent page(s)? I prefer the other importScript-like ideas.
I'd much prefer if we made creating a globalScript synchronous and with no
network request. The async load of iframes with an empty src is really
frustrating to web developers and causes lots of bugs and performance
problems in practice.
If we keep this syntax, we should at least try and special-case leaving out
the url argument so that we load the globalscript synchronously. I'm not
sure if this is really feasible given the time it takes to create a
Document, but we should at least try it and measure the performance..
> to have this:
> <webkit-globalscript name='...', src='url', onload=...
> This actually displays one of the issues i have with global script as a
> concept, you are basically just doing<iframe src="..."></..>
> And that gives you a context that achieves almost everything the global
> script concept gives you.
People keep saying that this is no better than a new window or an iframe
because you can script those synchronously across pages, but that totally
misses the point. The the frame/script/window survives when it's parent page
is closed if there's another page pointing to it and, in some versions of
this proposal, it survives same-origin page navigations. That isn't true of
iframes or windows and is exactly what makes these useful.
For the record, I'm on the fence about this idea, but it seems worth
experimenting with if there are web pages that will follow through with
using them, understanding that they're experimental APIs of course.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev