Re: Widgets 1.0

On Thu, 22 Feb 2007 08:36:05 +0100, Marcos Caceres <m.caceres@qut.edu.au>
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 <singpolyma@gmail.com> 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.

Received on Friday, 23 February 2007 17:19:28 UTC