Worst case, we can define something similar to 'fscommand' for widgets. However, I don't feel strongly about this ATM.
On more research, I've found that one can set window.resizeTo within a script to an alternate function, so this could be made to work :)
> >The bigger problem, if you're looking to embed these widgets in web pages > >is the security model of widgets, that allow for cross-domain > >XMLHttpRequest. > > This is indeed a problem. It can, again, be overcome if widget > designers wishing their widget to work on and offline were to use some > other method (such as an optional proxy URL, ala Netvibes), but it > would be nice if this were somehow supported in the actual > specification. Perhaps some sort of note could be made that there > SHOULD (if rendering in a webpage) be a variable in the JavaScript > (defined by the rendering system, ie, parent page) that contains a URL > to a proxy script (ie, http://example.com/proxy/?url=) and that if > this is present the widget code SHOULD access using this proxy. If > using a desktop rendering system (ala Google Desktop) there SHOULD NOT > be such a variable. If there is no such variable the widget code > SHOULD access resources directly. Sorry, this solution sounds a bit hackish to me. There are better ways to do off-line persistent storage. I also don't see how it addresses the XMLHttpRequest security issues Arve mentioned. Arve, I guess in regards to XMLHttpRequest security issue, the browser security model still applies.
:) I didn't expect this suggestion to make it into anything W3C related -- since it directly works to get around the security model. It is something many sites are doing with webtop-style widgets though :) -- - Stephen Paul Weber <http://webos.singpolyma.net/>
