On Thu, 22 Feb 2007 08:36:05 +0100, Marcos Caceres <[EMAIL PROTECTED]>
wrote:
I don't see why you could not embed a widget into a page using, say, a
HTML object element? In theory, the scope of the widget should not
conflict with the window scope of the web page (same as an iframe or a
flash movie). Could you please clarify your concerns a bit more?
Correct, the window object in the widget would be the same reference to
the window object any object or iframe has. Note that there are a few
methods you would not expect to work if an in-page widget was running,
such as moveTo or resizeTo, but the same applies for any object with a
window object (*ML documents in object/iframe).
Since the specification only specifies the move and resize methods of
the window object, what you are saying is that if embedded in a
webpage we would just have to accept that these widgets are not
allowed to move or resize themselves? This seems a bit odd. If the
widget rendering system (ie, the parent webpage) could be alerted to
the widget's wanting to be moved/resized, some systems would do it for
them, some would not, but it would be nice to have the option. I
understand the logic here, but it does limit implementation a bit
(which would likely end up being supplemented by an 'extended' but
non-standard Javascript library).
On 2/22/07, Stephen Paul Weber <[EMAIL PROTECTED]> wrote:
The Widgets draft <http://www.w3.org/TR/widgets/> seems to be meant for
offline widgets (ala Google Desktop). After inspection it does not seem
that it could even be 100% used because it defines a window object to be
accessible to the widget representing the widget's window (which
conflicts
with the browser window object representing the browser window).
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.
