- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 6 Nov 2009 17:19:59 +0100
- 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 UTC