Re: [widgets] Seeking comments on Last Call WD of Widgets: APIs and Events spec; deadline 15 Sept 2009

On 4 Sep 2009, at 15:46, Marcos Caceres wrote:

> On Fri, Aug 21, 2009 at 1:10 PM, Scott
> Wilson<scott.bradley.wilson@gmail.com> wrote:
>> Metadata Attributes and the Storage Area
>> ================================
>> I don't think its clear from the spec if metadata attributes are  
>> within the
>> scope of widget.preferences and must be stored in the same storage  
>> area.
>
> ok, I can try to clarify this. But I'm not sure where this is  
> confusing.

...

> Hmm. That is certainly not what was implied. They are totally separate
> things. Can you point me to the offending text in the spec?

It arises I think because Storage Area is defined just before the  
section on metadata attributes, without it explicitly stating "this is  
only used for storing preferences", with the possible interpretation  
that this is how a UA has to store all widget attributes. However that  
could just be me - I'll get some other people less familiar with the  
spec to read it and see if they make the same misinterpretation.

> Agreed. I think we have consensus in the WG that 2 is what we want and
> what should have been in the spec all along.

Great, I'm happy with that too, just need to figure a way of making it  
unambiguous in the text.

>> Read-only Metadata Attributes
> From my understanding is that private members can be used in  
> Javascript:
>
> http://www.crockford.com/javascript/private.html
>
> Hence, it would be possible for a javascript implementation of the
> spec to comply.

Thanks for the link, I hadn't found anything as clear as this before -  
I'll investigate this over the weekend and report back - it looks  
hopeful!

> Having said that, as the spec says, the interfaces are defined in
> terms of IDL which already defines readonly:
>
> "The attribute is read only if the "readonly" terminal is used in the
> definition. An object that implements the interface on which a read
> only attribute is defined will not allow assignment to that attribute.
> It is language binding specific whether assignment is simply
> disallowed by the language, ignored or an exception is thrown. "

>
> To include the text you suggested would be a tautology (and possibly
> lead to further confusion, as it redefines readonly). For a
> script-based implementation, I would follow this document:
>
> http://ejohn.org/blog/javascript-getters-and-setters/
>
> The fact that JS still allows you to delete properties is not the
> fault of the implementation (it's a consequence of the platform on
> which the implementation is done). The implementation should still be
> able to conform (read "pass the test suite") even though such a thing
> can happen.

>
>> So a web browser implementing the spec can declare the attributes  
>> in the
>> Window and make them read-only as it controls the environment, and  
>> Wookie
>> can just not save any changes beyond the scope of the current browser
>> session.
>
> Right.

Thats great - OK I'm happy with that for the conformance issue.

>
>> Section 5.1 and "syntactic sugar"
>> ==========================
>> Section 5.1, para 4 reads:
>> "Upon invocation of the setItem() or removeItem() method by an author
>> script on a protected key, user agent must throw
>> a NO_MODIFICATION_ALLOWED_ERRexception. The  
>> NO_MODIFICATION_ALLOWED_ERR is
>> defined in the [DOM3Core] specification."
>> OK, this is fine, we can implement this. However, what about:
>> widget.preferences.blah = "new value"; // where "blah" is a read- 
>> only key
>> We really don't have any way to prevent this happening or throwing an
>> exception. Luckily for us the conformance statement above doesn't  
>> mention
>> it, which means we don't have to!
>
> Hmm...
>
>> However I don't think this was the intention - it just shows one of  
>> the
>> problems with the "syntactic sugar" interpretation of WebStorage.  
>> For any UA
>> other than a browser, you really don't get the option to protect  
>> exposed
>> javascript properties.
>
> Are you absolutely sure about this? No fancy closures, or using
> Crockfords' methods will help here?

I'll check it out and see - fingers crossed.

>
>> I suggest changing the example in 6.4.2 to use getItem(), and  
>> adding a note
>> re: alternative syntax.
>> Personally I'd rather exclude them for the sake of  
>> interoperability. If not,
>> 5.1 para 4 & 6.4 para 4 need changing to cover semantically- 
>> equivalent
>> operations using alternative syntaxes; however unless the conformance
>> requirement is reworded as per my suggestion above for read-only  
>> metadata
>> attributes, we probably have to give up any hope of ever conforming  
>> to the
>> spec :-(
>
> Nah! we will work it out :)

:-D

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