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

Re: [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: Fri, 6 Nov 2009 17:19:59 +0100
Message-ID: <b21a10670911060819v38d3b838x65ff3802a5832af7@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
2009/11/3 Marcos Caceres <marcosc@opera.com>:
> 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
> out:)).
>
> 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.html
> <html>
> <a href="b.html" > Go to B</a>
>
> b.html
> <html>
> <a href="c.html" > Go to C</a>
>
> c.html
> <html>
> <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
> orientation.
>
> 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
> above.

After luring an unsuspecting Hixie into our widget meeting:), we
basically concluded that a widget instance is as follows:

"A widget instance is a browsing context that comes into existence
after initialization. The concept of a browsing context is defined in
[HTML5]. Multiple widgets instances can be instantiated from a single
widget package. Every widget instance is universally unique, meaning
it does not share any attribute values or storage areas with any other
widget instance."

Kind regards,
Marcos


-- 
Marcos Caceres
http://datadriven.com.au
Received on Friday, 6 November 2009 16:20:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT