On 7/20/09 4:45 PM, Robin Berjon wrote:
On Jul 20, 2009, at 16:08 , Marcos Caceres wrote:
In the widgets API spec, what are the advantages of having a
widgets.preferences attribute when the window.localStorage is already
available on the window object?
I think we should:
1. Drop widget.preferences, but require a UA to implement
[WebStorage] (which we already do!).
2. Pre-populate the window.localStorage with the value of
<preference> elements in the config document (no events are fired
during pre-population!).
3. "Protect" read-only preferences, meaning:
A. At runtime, throw a NO_MODIFICATION_ALLOWED_ERR exception
upon any attempt to invoke the setItem() or removeItem() methods.
B. upon the attempted invocation of the clear() method, a user
agent must not remove the key-values of the protected preference from
a storage area.
WDYT?
I think it's dodgy. Basically this would mean reusing a well-known
attribute but giving it different behaviour, which in general is a bad
idea. The "vanilla" localStorage would never throw in such ways, and
would clear() the protected preferences.
Not if we said it couldn't:)
This change means that
localStorage won't work the same way for a given document if that
document is in a widget or not. I don't think that's a good idea.
Fair enough.
The cost of having preferences there is very low, and it makes sense
semantically. Why remove it?
Ok, so, widget.preferences MUST NOT equal window.localStorage. The are
separate things. Both can be used. Right?
Kind regards,
Marcos
