Re: Comments on localStorage

On Fri, 17 Oct 2008, Philip Taylor wrote:
> 
> In the second example: "localStorage.pageLoadCount = 
> parseInt(localStorage.pageLoadCount, 10) + 1;". I think it would be 
> helpful to add a comment like "// localStorage values are always 
> strings, so they should be explicitly converted to integers if they will 
> be used numerically" to tell people what the parseInt is for, since it's 
> a fairly non-obvious feature of JS.

Done.


> Why use parseInt(..., 10) instead of just parseInt(...) (which defaults to
> decimal (unless the string begins with "0x"))?

Because I don't want "010" to become "8". Sometimes users enter numbers 
with leading 0s and it confuses them when they get handled that way.


> For key(n): "If n is less than zero ... then this method must raise an 
> INDEX_SIZE_ERR exception" - how can it be less than zero, when the IDL 
> says it's an unsigned long?

Good point.


> "When the localStorage attribute is accessed, the user agent must check 
> to see if it has allocated local storage area for the for the origin of 
> the active document of the browsing context of the Window object on 
> which the method was invoked." - s/allocated local/allocated a local/, 
> s/for the for the/for the/

Fixed.


> "When the localStorage attribute is accessed, ... The user agent must 
> then create a Storage object associated with that origin's local storage 
> area, and return it." - that's saying it must create a distinct new 
> object for every single access to localStorage, which can't be right. 
> (If it was right, then phrases like "[the] Window object's localStorage 
> attribute's Storage object" wouldn't make sense, because there wouldn't 
> be only one Storage object associated with that attribute.)

Fixed.


> "the user agent must dispatch an event ... which uses the StorageEvent," -
> should say "the StorageEvent interface"

Fixed.


> What should oldValue be if I call removeItem(key) where key is not in 
> storage? (There is no old value, but it's not newly added either, so 
> this seems unspecified.)

Clarified.


> When defining "The storage event": "address of the page" should link to 
> a definition of exactly what that means.

Fixed.


> When defining StorageEvent: "The url attribute represents the address of 
> the document that changed the key." - no it doesn't (I think) - if one 
> document changes the localStorage of another document, it's the address 
> of the second document.

Fixed.


> "The source attribute represents the Window that changed the key." - ditto.

Fixed.


> In the Threads section, "Multiple browsing contexts must be able to 
> access the local storage areas simultaneously in a predictable manner" 
> seems impossible to satisfy, since if two try to access the local 
> storage at the same instant then I can't predict which one will get in 
> first, hence it's unpredictable (even though that's a perfectly sensible 
> way to implement concurrency). It could perhaps be made clearer by just 
> stating that concurrent script execution must be serializable with 
> respect to localStorage, i.e. the final state of the localStorage object 
> must be equivalent to the state after some (any) serial execution of the 
> scripts.

Fixed, ish. Let me know if you like it how it is now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 24 December 2008 12:42:00 UTC