- From: Marcos Caceres <marcosc@opera.com>
- Date: Tue, 3 Nov 2009 09:15:43 -0800
- 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 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. -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Received on Tuesday, 3 November 2009 17:16:43 UTC