On Thu, Feb 4, 2010 at 10:19 PM, Cyril Concolato
<cyril.concol...@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
