Not if tries it to manipulate the DOM.. or do anything else the same origin policy applies to.
I think if iGoogle insists on caching the gadget definition, that it should also cache external js, and replace the links with their own. Or they could make it possible to use their caching APIs to load js, and document how to do so. It might already be possible, but I don't know if the origin of the content out of their caching API is the same as that of the cached gadget definitions, and even if it is I would never count on that being the case. I'm also fairly certain I could use the cache API to load a js as text and then eval() it, but I've seen too much weirdness with that approach to use it for anything but very simple, small javascript statements. On Jul 16, 6:17 pm, Justin McConnell <[email protected]> wrote: > On Jul 16, 2:35 pm, jonathaz <[email protected]> wrote:> Also, this > antiquated design breaks support for > > external javascript, relative URLs, etc. (again unless using > > type=url). External javascript referenced in a gadget definition, for > > example, won't work in Google Chrome or Safari. > > <script type="text/javascript" src="http://bayareacoder.com/gogo/ > localweather/tinyxmlsax.js"></script> > This will work in any browser that supports script tags. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iGoogle Developer Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Gadgets-API?hl=en -~----------~----~----~----~------~----~------~--~---
