W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [widgets] TWI: comments

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 8 Feb 2010 16:56:22 +0100
Message-ID: <b21a10671002080756i46ab5f7dp88d12b8dc5ec6098@mail.gmail.com>
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 GMT

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