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

[Scott Wilson]

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

On Fri, Aug 21, 2009 at 1:10 PM, Scott
Wilson<scott.bradley.wil...@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

defined in the [DOM3Core] specification."
OK, this is fine, we can implement this. However, what about:

We really don't have any way to prevent this happening or throwing an

it, which means we don't have to!

a NO_MODIFICATION_ALLOWED_ERRexception. The NO_MODIFICATION_ALLOWED_ERR is widget.preferences.blah = "new value"; // where "blah" is a read- only key exception. Luckily for us the conformance statement above doesn't mention

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.

operations using alternative syntaxes; however unless the conformance

spec :-(

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 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

Nah! we will work it out :)

:-D

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

smime.p7s
Description: S/MIME cryptographic signature