- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 8 Feb 2010 16:56:22 +0100
- To: cyril.concolato@telecom-paristech.fr
- Cc: public-webapps <public-webapps@w3.org>
On Thu, Feb 4, 2010 at 10:19 PM, Cyril Concolato <cyril.concolato@enst.fr> wrote: > Hi all, > > While trying to implement the widget interface spec [1], I found two typos: > - "a user agent can to support" => "a user agent can support" > - missing closing parenthese "in conjunction to the preferences attribute)". fixed > I have also some remarks/questions: > > * "A user agent whose start file implements [HTML5]'s Window interface MUST > ..." > The start file does not implement anything. The user agent implements. I > suggest to change it to something like: > "User agent implementing the [HTML5]'s Window interface MUST ..." Fixed > * Section 5. is called "Widget Interface" but it starts by saying "The > widget object provides ...". It think it should say "Objects implementing > the widget interface provide ..." Fixed > * The step 1 in the initialization of the preference attribute algorithm > which says "Establish the instance of a widget for this widget and create a > storage area that is unique for the origin." should probably say "unique for > the origin and for that instance." Right, fixed. > * The spec says: > "When an object implementing the Widget interface is instantiated, if a user > agent has not previously associated a storage area with the instance of a > widget, then the user agent must initialize the preferences attribute." > What happens if the UA has already associated a storage area ? It should > probably say that no initialization of the preferences attribute is made but > the associated storage area can be used using the Storage interface, no ? Right, I've adapted your text to read: "When an object implementing the Widget interface is instantiated, if a user agent has not previously associated a storage area with the instance of a widget, then the user agent must initialize the preferences attribute. If a user agent has previously associated a storage area with a widget instance, the user agent must not re-initialize the preferences attribute unless explicitly requested to do so by the end-user or for security reasons. Instead, the previously associated storage area (or an equivalent clone) can be accessed using the Storage interface." Does that make any sense? > *In case two instances of the same widget package are loaded, modified (e.g. > weather in Paris and in New York) and then closed, how does the UA retrieve > the associated storage area when one is reloaded ? I don't think it can be > specified but I think you should probably add a note saying that it is > implementation specific, for example by asking the user what previous > instance it want to start first. I personally think this is too implementation specific to comment on and there are just too many ways to solve this problem (e.g., order closed = order open, user prompting, etc.). > * What happens to the "storage" event fired by the setItem or removeItem > methods when the UA does not implement the window object ? ... hmm... seems that Storage is tied to Window... bah. This goes back to my previous email [1] about the window object. I think we need to just bite the bullet and just put the Window dependency in :( > * What is the return value for the openURL method when there is a scheme > handler associate to the IRI ? When there is none, the text says the method > returns void. I think it also returns void so I wonder what's the point of > the paragraph. Right. This whole openURL section needs a minor clean-up: there is a bit or redundancy there. Let me work on that an get back to the WG. > * The IDL spec indicates that the preference attribute implements the > Storage interface, but I can't find a 'real' sentence saying it. I find: > "Note: A user agent can support the Storage interface on DOM attributes > other than the preferences attribute (e.g., a user agent can to support the > [WebStorage] specification's localStorage attribute of the window object in > conjunction to the preferences attribute)" but this is a note, hence not > normative. Well spotted! The definition of preference now reads: "The preferences allows authors to manipulate a storage area that is unique for the instance of a widget. It does this by implementing the Storage interface specified in [WebStorage]." > "Return the Storage object associated with that widget instance's > preferences attribute." but that's not really explicit. Right. Given the clarification above, this should now make more sense. > "Implement the Storage interface on the storage area, and make the > preferences attribute a pointer to that storage area." but this isn't as > clear as "The UA MUST support the Storage interface on the preferences > attribute" or similar... Given the redefinition of the preference attribute, it's a statement of fact that the preference attribute supports the Storage interface. The conformance requirements around that fact are tested through the various algorithms and behavior imposed by the specification. > I suggest that you add an additional sentence. Also, the given example is > not really clear because it does not show the relationship between a > config.xml document with preference elements and the associated script and > storage. That's a good point. I've added another example to the spec. Can you please take a look? > Finally, can you clarify if the usage of getItem / setItem such as in > widget.preferences.getItem('foo'); and widget.preferences.setItem('foo', > 'dahut'); is allowed or if only the brackets notation > (widget.preferences['foo']) is allowed. Maybe by adding an example ? As of WebIDL , I believe the notations are equivalent. Regardless, I have added an example. Please see the spec. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0496.html -- Marcos Caceres http://datadriven.com.au
Received on Monday, 8 February 2010 15:57:13 UTC