Re: [A&E] Last Call comments (1)

2009/9/15 Marcin Hanclik <Marcin.Hanclik@access-company.com>:
> The below comments refer to:
> Widgets 1.0: The widget Interface
> Editor's Draft 14 September 2009
>
> General:
> Replace "can" with "may" in the whole document.

I've used can deliberately throughout the document where statements of
fact are made. To use may would result in a conformance clause where
one is not needed.

> 2.
> Feature
> Why to repeat the definition from P&C?

People complain about having to jump from spec to spec. Makes the
document easier to read.

> Getting / Setting
> Refer to HTML5 for those definitions?

No, they are defined in WebStorage but I stole them  (muahaha!) :) I
only reference other specs where something that affects
conformance/behavior is said.

> Viewport
> [1] says that scrollbars are part of the rendering area
> (I do not claim that it is fully correct, I assume scrollbars are a discussion point, specifically in the context of DHTML where they could appear and vanish depending on the dynamic content).
> My proposal is to make this definition non-final.
>
> All definitions:
> Could we have a document with the definitions for all specifications from the family?

That could be possible, but some definitions are inline - better to
leave them where they are and just follow the anchors in the document.

> 3.
> achived -> achieved

Fixed.

> 4.
> Again about the definitions:
> Could we have a common definition of the user agent, decoupled from the specs?
> (e.g. UA in P&C is an implementation, here it is a software implementation)

Yes, we have talked about this but just haven't got around to doing
it. I personally don't think we need an overarching definition,
however. The more modular these specs are, the better IMO. We try to
make it pretty clear what the dependencies for each UA are.

> 4.2
> a read-only item is an item in a storage area cannot be ...
> should be
> a read-only item is an item in a storage area that cannot be ...

Fixed.

> 5.
> Why aren't the following attributes available on the widget interface?
> @viewmodes from <widget>,

That's your spec :) Add it as supplemental attribute to the widget interface.

> @short from <name>,

I would not mind adding this one, maybe calling it widget.shortname.

> @href from <license> and license,

What is the use case?

> icons

What is the use case? Also, these may be changing dynamically so it
makes things a mess.

I think we should create and Icon API at some point in the near future
(leverage HTML5 cross-doc communication), but we should not add
anything poorly specified now.

> 5.
> It preferences(via the preferences attribute).
> Unclear.

Yikes, changed it to:
"The interface also allows authors to access persistently-stored
preferences (via the preferences attribute)."

> 5.
> A user agent should to impose ...
> Should be
> A user agent should impose ...

I've deleted that assertion (Artb pointed out that it is an untestable
weasel assertion).

> 5.
> ... global object context of the widget's start file.
> What about:
> ... global object context of the document loaded from widget's start file.
> ???

I'm working on a better definition for this with Robin.

> 5.
> In
> ... global object context of the widget's start file.
> And
> A user agent whose start file implements HTML5's Window interface ...
> The "start file"s refer to 2 different locations.

I'm going to rewrite all this. Will let you know as soon as it is done.

> 5.4
> How to handle multiple instances of the same widget?
> As far as I remember it was to be moved to WURIv2, but it seems important in the context of preferences.

No, it's not important. They are bound to the origin of a widget as
defined in WURI, and the origin of a widget is universally unique.
Hence, preferences are unique and not shared.

> 5.4
> Storage interface:
> The A&E specification should not add interpretation to the WebStorage with regard to the exceptions thrown. It would be better to improve the WebStorage specification.
>

Hixie was the one who said we need to define it here. There is no
notion of a read-only items in Web Storage. We can ask Hixie again,
but I doubt he will pay us any attention (besides, I agree with him.
It should be spec'd in our spec... no need to bloat WebStorage with
widget-only stuff).

> Specifically the NO_MODIFICATION_ALLOWER_ERR shall be presented in WebIDL on Storage interface based on "raises" keyword of WebIDL.
>

That would be nice. I don't know any WebIDL. Do you want to write a
supplemental IDL declaration for us to include in the spec? We can
live without it, but would be nice to have (makes the spec easier to
understand).

> 5.4.1
> onClick -> onclick

Fixed (though I don't think case matters in HTML5, the parser still
works it out)

> 5.4.2#3
> ... make the preferences attribute a pointer that storage area.
> Should be
> ... make the preferences attribute a pointer to that storage area.

Fixed.

> 5.4.2#2.4.1
> ... apply the  rule for dealing with an invalid Zip archive ...
> And
> "In the event that an implementation encounters an invalid Zip archive ...
> In the case the UA is a CC, it must inform the author that the Zip archive is an invalid Zip archive." From P&C.
>
> Do not play well together.
> The problem is with the WUA and not with the widget, so the correct information should be provided to the user.

Sorry. I don't understand the problem, can you elaborate? Are you
saying that all UAs (not just CCs) must inform the end-user of the
error?

> The problem
> 5.5
> ... should open the provided iri ...
> What does opening of the IRI mean?
> Maybe this would work (IRI handler could be defined anyway) :
>
> ... should handle the provided iri ...

I like it. Used your text.

> 5.5
> ... it is otherwise rejected by the user agent (e.g., because of security policy or user prompting), or iri is not a valid IRI, then the user agent must act as if the method had not been invoked.
>
> The user agent should inform the end-user when a request to handle the IRI via the openURL() method has failed.

Ok, I agree. I will specify this and let you know once it is done.

> The above requirements seem contradicting and not prepared for handling the security policy.

Which "security policy"?

> a) acting as if the method had not been invoked (a MUST) and informing the end user (a SHOULD) may not work well together.
> b) it should be possible for the UA to reject the call to openURL, and then the exception or error shall be thrown, so that the script could catch it and inform the user.
> I suggest leaving the WebIDL for openURL to DAP.

So you suggest we take this method out of this spec?

> 5.5
> Last sentence seems to be lost in action.

FIxed. Added "invoked".

(there is stupid bug in my editor which keeps deleting lines for no
reason! :( )

> [1] http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html

-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 23 September 2009 16:11:11 UTC