- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 20 Jul 2009 17:32:29 +0200
- To: Robin Berjon <robin@berjon.com>
- CC: public-webapps <public-webapps@w3.org>
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
Received on Monday, 20 July 2009 15:33:13 UTC