W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

[widgets] Definition of Instance was: Comments on Section 6 of the 18-Aug-2009 LCWD of A&E spec

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 3 Nov 2009 09:15:43 -0800
Message-ID: <b21a10670911030915o46d59811lbf461b6918fc3a3c@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
2009/9/15 Robin Berjon <robin@berjon.com>:
> On Sep 15, 2009, at 15:46 , Marcos Caceres wrote:
>> Robin Berjon wrote:
>>> On Sep 13, 2009, at 23:23 , Marcos Caceres wrote:
>>>> That is, because widget is assumed to be bound to the global scope of
>>>> widget, we can test for it's presence without needing to qualify the
>>>> object with it's global context (which, normally would be 'window'.).
>>>> The problem is that what is meant by the "global object context" is
>>>> not defined. We might need to leech some HTML5 terminology to make
>>>> this more clear.
>>> Hmmm, I think that we can reference E262 for that, it ought to be enough
>>> (and then implementations normally make that window, but that's not for
>>> us to say).
>> That might work. Nothing in WebIDL?
> Not that I know of. The way SVG Tiny 1.2 worked its way around that dependency was by referring to the document's defaultView instead:
>  http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window
> I think we could do the same.
>>> One thing I'm not sure about: in the start file only?
>> Good point.
> I guess we need something roughly saying "any JS global context that is also a widget execution context".

The "widget instance" definition needs to be crystal clear as it is
effectively the definition of a widget instance makes or breaks W3C
widgets, IMO (and testing is showing that this is a massive interop
issue!): Without a clearly defined for an instance concept, storage,
cookies, view modes, etc.  wont work in an interoperable manner.

I can't stress enough how fundamental this definition is to the
architecture of widgets (I know, I'm getting all dramatic, but hear me

I'm trying to bring together the concepts of DefualtView, ViewPort,
Window, Document, etc. here and these interfaces/things MUST be part
of this definition. Without those concepts, a widget instance is just
fluff. However, the terminology is really killing me here... so I'm
just going to list the requirements:

1. Given a widget package, I can instantiate multiple instances of
that widget.

So, from clock.wgt in can instantiate N instances. For example, one
can create a separate instance of the widget  for Boston, New York,
Madrid, Santa Clara, etc.

2. The storage areas are not shared and are protected from other
widgets of the same ilk.

So, for example, setting the location of the Boston clock does not
affect any of the other clocks.

3. Widget instances can be locally "navigated", meaning that the files
inside the widget can be hyper-linked. Navigating to a resource
outside the widget package is not allowed, but iframes certainly are.

So if I have a widget with the following files: a.html, b.html,
c.html. Then I should be able to navigate them as normal:

<a href="b.html" > Go to B</a>

<a href="c.html" > Go to C</a>

<iframe src="http://foofum.com" />
<a href="a.html" > Go to A </a>

4. preferences are accessible by all documents or an instance.

So if I have a widget with the following files: a.html, b.html,
c.html. All those files can access the same preferences.

5. Instances are clonable.

It should be possible to deep-clone an instance, though the spec does
not need to say anything about this. For example, if I have an
instance of a clock widget, I should be able to clone it to have
another clock widget already set to whatever locale the first widget
was set to.

6. Styles must be applicable on a per viewport level so that widgets
can be locked into either portrait, landscape, or free to change

For example, if I navigate to a page with a video (intro.html), I
should be able to re-orientate the widget into landscape mode. Then
swap the widget to a portrait mode when it is navigated to menu.html.

That is how I want widgets to work. Plain and, um, simple. The
definition of a widget instance needs to allow all the things I listed

Marcos Caceres

Marcos Caceres
Received on Tuesday, 3 November 2009 17:16:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC