On Tue, Sep 1, 2009 at 9:58 PM, Ojan Vafai<[email protected]> wrote: > On Tue, Sep 1, 2009 at 9:07 PM, Oliver Hunt <[email protected]> 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, >> errorHandler); > > 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..
Not to harp, but for lack of a missing abstraction (Deferreds or Futures, or whatever your particular CS dept called them), we've seen every JS library on the planet re-invent some "onready" abstraction when the built-in events don't quite cover it. This is just another place where having a uniform for way to listen for a single event (which possibly already happened) would turn this into a simpler problem. Something like: var globalScript = new webkitGlobalScript(name); // ...time/flow control passes... globalScript.onready(handler); // ...time passes.... globalScript.src = "...."; // ...time passes, ready happens.... // handler is called immediately on registration since future already arrived. globalScript.onready(anotherHandler); Regards >> to have this: >> <webkit-globalscript name='...', src='url', onload=... >> onerror=...></webkit-globalscript> >> >> 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. > Ojan > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
