12111 2011-02-17 15:17:57 +0000 spec for Storage object getItem(key) method does not match implementation behavior 2011-08-04 06:50:58 +0000 1 1 1 Unclassified WebAppsWG Web Storage (editor: Ian Hickson) unspecified PC All RESOLVED FIXED P2 normal --- 1 mike ian adrianba annevk ap art.barstow ayg ian jorlow me mike plh public-webapps public-webapps-bugzilla oldest_to_newest 45772 0 mike 2011-02-17 15:17:57 +0000 http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that "The getItem(key) method must return a structured clone of the current value associated with the given key." but all browsers I've tested return a string representation of the value instead. 49023 1 ian 2011-06-01 17:39:04 +0000 This is just because the spec added this feature after the last round of implementations, but I'll mark this REMIND so I can look into it again in a few months and see where we stand. 49026 2 plh 2011-06-01 18:12:35 +0000 A spec that does not match implementation behavior doesn't seem useful to me. Is there any reason to think that the implementations will change? 49033 3 ayg 2011-06-01 20:19:01 +0000 I seriously doubt the specced behavior is web-compatible. For instance, I myself just discovered this when trying to store booleans in localStorage, and worked around it by testing localStorage["foo"] != "false". If localStorage["foo"] = false suddenly actually sets it to false instead of "false", this will break. 49056 4 art.barstow 2011-06-02 11:30:08 +0000 Aryeh, PLH - please make a concrete proposal (e.g. diff) that addresses your comments. 49057 5 plh 2011-06-02 12:31:42 +0000 here is how the change should look like I think: [[ interface Storage { [...] getter DOMString getItem(in DOMString key); setter creator void setItem(in DOMString key, in DOMString value); [...] }; [...] The getItem(key) method must return the current value associated with the given key. If the given key does not exist in the list associated with the object then this method must return null. The setItem(key, value) method must set the value of a given key. If this raises an exception, then the exception must be thrown and the previous value associated with the given key is left unchanged. ]] For forward compatibility purposes, I would not change the types of oldValue and newValue in the StorageEvent interface. In practice, those will be DOMString since that's the only thing one can store, but this could change in the future if we add a getValue and a setValue methods to the Storage interface with the type any. 49077 6 me 2011-06-02 20:55:16 +0000 I talked with some other folks at Mozilla (Jonas Sicking and Ben Turner) about this and the general feeling seems to be that we're not particularly interested in implementing structured clones for localStorage values. In addition to the web compat concerns, improving localStorage doesn't seem to be a good investment of time and resources, and runs the risk of encouraging more developers to use an API we'd rather they didn't. The isn't an official statement that we won't implement it (it's still open in our bug tracker at https://bugzilla.mozilla.org/show_bug.cgi?id=538142), and some other Mozilla people might disagree with me here. 49142 7 jorlow 2011-06-03 08:47:14 +0000 Kyle's comment also applies to Chromium. (Including the fact that some folks may disagree, but I believe it's the predominate opinion of the developers working on it.) 49165 8 ap 2011-06-03 17:12:44 +0000 I don't think that it matters too much whether developers manually serialize to JSON or the engine does that for them. Having engine help would be good for consistency of the platform, as you should be able to assign persistent properties to localStorage and sessionStorage objects exactly like you do it for any JavaScript object. There is no technical reason to require the quirk of only allowing string properties, and I would personally like to have arbitrary properties implemented in WebKit eventually. 49202 9 ayg 2011-06-05 18:20:19 +0000 (In reply to comment #6) > I talked with some other folks at Mozilla (Jonas Sicking and Ben Turner) about > this and the general feeling seems to be that we're not particularly interested > in implementing structured clones for localStorage values. In addition to the > web compat concerns, improving localStorage doesn't seem to be a good > investment of time and resources, and runs the risk of encouraging more > developers to use an API we'd rather they didn't. What should they use instead? localStorage serves a very useful purpose as a simple persistent key-value store. If it has problems, like locking or synchronousness, we need to either fix them or come up with a tenable replacement. The only one I'm aware of in the works is IDB, which doesn't even come close to being simple enough to be a localStorage replacement. 49203 10 jorlow 2011-06-05 18:35:49 +0000 (In reply to comment #9) > (In reply to comment #6) > > I talked with some other folks at Mozilla (Jonas Sicking and Ben Turner) about > > this and the general feeling seems to be that we're not particularly interested > > in implementing structured clones for localStorage values. In addition to the > > web compat concerns, improving localStorage doesn't seem to be a good > > investment of time and resources, and runs the risk of encouraging more > > developers to use an API we'd rather they didn't. > > What should they use instead? localStorage serves a very useful purpose as a > simple persistent key-value store. If it has problems, like locking or > synchronousness, we need to either fix them or come up with a tenable > replacement. The only one I'm aware of in the works is IDB, which doesn't even > come close to being simple enough to be a localStorage replacement. Fixing local storage has been discussed ad nauseum. It can only be done with major backwards incompatible changes. We've also talked about creating a new API and the sentiment is that we already have 3. At this point, more churn is probably not the right answer. Getting one API (IndexedDB) right, letting library developers (like lawnchair) fill in the gaps in the mean time, and making an educated decision in the future seems like a much better answer. 49223 11 adrianba 2011-06-06 19:25:53 +0000 (In reply to comment #10) > Fixing local storage has been discussed ad nauseum. It can only be done with > major backwards incompatible changes. We've also talked about creating a new > API and the sentiment is that we already have 3. At this point, more churn is > probably not the right answer. Getting one API (IndexedDB) right, letting > library developers (like lawnchair) fill in the gaps in the mean time, and > making an educated decision in the future seems like a much better answer. I agree. This was raised back in November after TPAC: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0773.html http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0798.html Our plans have not changed: We have no plans to change the behaviour of Web Storage in IE to support structured clones. We believe IndexedDB represents a better mechanism for storing structured data in the Web Platform. 49912 12 annevk 2011-06-20 10:44:01 +0000 I was asked to state Opera's position here. We do not feel strongly either way. If we indeed want people to move away from this API it would probably be better to keep it string-based so no extra implementation cycles are needed for a feature that is to be avoided. 49915 13 ayg 2011-06-20 14:24:52 +0000 What's Opera's position on the compat implications? 49916 14 annevk 2011-06-20 14:28:18 +0000 Making that transition is doable probably, but it is unlikely we will get that far seeing that no implementor apart from ap is really interested. 54148 15 ian 2011-08-04 06:50:44 +0000 Since browser vendors are no longer interested in using Web Storage for structured data, I've moved the spec back to just strings. 54149 16 contributor 2011-08-04 06:50:58 +0000 Checked in as WHATWG revision r6364. Check-in comment: Remove the structed data support from Web Storage. http://html5.org/tools/web-apps-tracker?from=6363&to=6364