Hi All,
WebApps-WG recently asked Tim Kindberg, editor of the TAG URI scheme, if
could make some comments about the widgets' requirements for a URI scheme.
Below, Tim agrees that tag: is probably suitable for widgets, but raises
some concerns about i18n and having a resolution algorithm to go
Requirements related to widgets should be clearly stated, even if
mechanisms can be used beyond widgets.
Thus if widgets need expiration then we should be able to articulate
both the use case and the requirement.
Thanks for updating the requirements document for the other items.
BTW: When it comes to some page/web-app instantiating a widget... how does
the
publisher/developer make reference to the widget to be instantiated and/or
the
package from which it is to be instantiated (if those are regarded as
separate
things)?
I'm sorry, I'm not sure I
On Jan 16, 2009, at 6:10 PM, Jonas Sicking wrote:
On Fri, Jan 16, 2009 at 5:17 PM, Nikunj Mehta
nikunj.me...@oracle.com wrote:
I have reviewed the draft specification dated 1/14 [1]. I am not
sure about
the status of this spec vis-a-vis this WG. Still, and without having
reviewed any
On Tue, Jan 20, 2009 at 9:57 AM, Nikunj Mehta nikunj.me...@oracle.com wrote:
On Jan 16, 2009, at 6:10 PM, Jonas Sicking wrote:
On Fri, Jan 16, 2009 at 5:17 PM, Nikunj Mehta nikunj.me...@oracle.com
wrote:
I have reviewed the draft specification dated 1/14 [1]. I am not sure
about
the
Hi All,
In the current Widgets 1.0: Packaging and Configuration specification
[1], the window modes feature is identified as being at risk. Vodafone
believes that window modes are an important feature and should be
supported in Widgets 1.0. This email provides a proposal for how modes
could be
Hi Frederick,
On Tue, Jan 20, 2009 at 4:23 PM, Frederick Hirsch
frederick.hir...@nokia.com wrote:
Requirements related to widgets should be clearly stated, even if mechanisms
can be used beyond widgets.
Thus if widgets need expiration then we should be able to articulate both
the use case
On Fri, 16 Jan 2009, Jonas Sicking wrote:
So I think it'd be nicer to have parity with other onX properties, than
to have parity on this one aspect with window.onerror.
Done.
Second, does the spec define what happens if an error is thrown from
'error' event handler?
Now fixed.
--
